[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quanta-devel
Subject:    Re: [quanta-devel] VPL toolbars
From:       Andras Mantia <amantia () kde ! org>
Date:       2005-03-09 12:13:05
Message-ID: 200503091413.05632.amantia () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 09 March 2005 04:55, Paulo Moura Guedes wrote:
> On Tuesday 08 March 2005 17:15, Paulo Moura Guedes wrote:
> > On Tuesday 08 March 2005 16:22, Andras Mantia wrote:
> > > Now what about the word-processor like behavior? This should also
> > > be a global behavior both in source and VPL. You can look up the
> > > DOM tree for the tag name that is about to be inserted and remove
> > > from there if it's already present. Same thing can be done in the
> > > source in the Node tree.
> >
> > A button will eventually be toggled when:
> > 1. it is pressed
> > 2. the cursor node changes
> >
> > 1. This calls TagAction::insertTag()
> > It seems that TagAction objects are created at startup and don't
> > have any information about the toolbar buttons. How can one toggles
> > the buttons from here?

The toolbar buttons just a visual way of representing the TagAction. You 
should think about TagAction as about any KAction in the code (as it's 
basicly a KAction). Whenever it is activated (button pushed on the 
toolbar, menu entry selected, keyboard shortcut used) the insertTag is 
called. The name "insertTag" is weird and I'm about to rename it to 
something like "slotActivate". 

Right now toggle actions are not supported in TagAction, but we can fix 
this for 4.0. :-)


> > 2. this is easy in VPL as a signal is emmited when the cursor node
> > changes but not so easy in source.... anyway we still have the
> > problem of controlling the buttons.

Why would be hard here? There is already a signal emitted by the 
KTextEditor called cursorPositionChanged () and we have code to find 
the node corresponding for the cursor position in the node tree 
(Parser::nodeAt).
And about controlling the button state: KToggleAction::setChecked  
(bool)

> > Perhaps we should define in DTEP which buttons are toggleable (<b>,
> > etc) or not (Quick Start Dialog, etc)?

Yes, definitely.


> Ok, the actions can be accessed trough actionCollection(). 

Why do you want to access them via actionCollection? The VPL specific 
code should go somewhere in TagAction::insertTag (as there already is 
some) or QuantaView::insertNewTag, Document::insertTag and possibly 
TagAction::slotGet* methods should be modified as well.

> Though, 
> some of them must be toggable, i.e., KToggleAction's instead of
> KAction's. How do you suggest to do that Andras? My shot is that we
> could create an attribute "toggable" in DTEP.

Not in DTEP, but in the action definition (inside the toolbar tarballs 
or actions.rc). And of course the Configure Actions GUI should be 
updated for Tag actions.

Andras

-- 
Quanta Plus developer - http://quanta.sourceforge.net
K Desktop Environment - http://www.kde.org

[Attachment #5 (application/pgp-signature)]

_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel


[prev in list] [next in list] [prev in thread] [next in thread]