Re: [Inkscape-devel] BUG and solution in align dialog
BTW, I finished refactoring the align dialog to use gtkmm
and more >>OO code.
Now I'll add the align nodes features.
How is it going to look in terms of UI? I think the most
intuitive
would be to make it work on selected nodes when the node
edit tool >is
active on the active desktop, and on selected objects
otherwise. >This
way you need no additional buttons or switches in the dialog.
Also it would be nice to disable all or some of the buttons depending on what is selected. Thus, if no objects or only object is
selected,
all align/distribute buttons are grayed out; if several
nodes are
selected, "distribute top/bottom/right/left" are disabled
because >they
make no sense for sizeless nodes (only distribute centers and equi-spaced remain).
That was what I was planning to do. But instead of grayed icons, I think I'll replace them by specific node align icons (node align vert, node align hor, node ditribute vert, node distribute hor).
To do so, if it's not already here, I'll add a stdc::signal<void, ToolIdent> _tool_changed; for the desktop.
I also would like to talk about the possibility to use
the dialogs >>like in
gimp2 (drag and dropable notebook tabs, multiple
instances of the >>same
dialog, etc) I started a very simple implementation, but I'm not sure
you want >>to do that.
Now I'm used to it, I find it easier to remember keyboard
shortcuts and have
transient dialogs. No mess with tabs. PLease let me know
your >>opinions.
Draggable notebook tabs may be a good idea - it will let
one combine
all the tabs used frequently into one dialog and have only
that >dialog
open, thus saving space. But it's likely to be rather
difficult to
implement, it will very much disrupt our old dialogs code.
Yes. But as we will refactor all the dialogs, that should be the right time to do it. The only thing needed is to make each dialog inherit from a class. For me the main question is the impact on the GUI. Do we keep buttons for calling each dialog ? How much docker areas can you create? How do you create one ? What happens with keyboard shortcuts ?
Multiple instances of the same dialog does not sound like a
good >idea
at all. I think it will be just confusing without any
advantage.
OK, so maybe a ctrl+shift+a shortcut could bring the align dialog in a new docker if it does not already exists. This way, you could still work as now, but w/ the ability to group several dialogs in one.
I was also wondering if we could split the fill dialog in 3 different dialogs, strarting in the same docker, but you could rearrange that, eg if you want to see in the same time fills and strokes ...
************************ ADSL ILLIMITE TISCALI + TELEPHONE GRATUIT ************************ Surfez 40 fois plus vite pour 30EUR/mois seulement ! Et téléphonez partout en France gratuitement, vers les postes fixes (hors numéros spéciaux). Tarifs très avantageux vers les mobiles et l'international ! Pour profiter de cette offre exceptionnelle, cliquez ici : http://register.tiscali.fr/adsl (voir conditions sur le site)
That was what I was planning to do. But instead of grayed icons, I think I'll replace them by specific node align icons (node align vert, node align hor, node ditribute vert, node distribute hor).
Yes, I like the screenshot in your blog. I need to play with it, however, to be able to comment more. What is your SF name so I could give you CVS access?
One idea I had is this: Imagine you have a path consisting of strict horizontal and vertical segments, and you want to distribute (some of the) vertical segments (not nodes!) equi-spacely. I think it's a pretty common situation, but distributing _nodes_ will break the verticality of segments. So I propose to add a (perhaps optional) rule: If two or more nodes are aligned vertically (within some tolerance), consider them one node and move them as a whole during horizontal distributions, and the same for horizontal alignment/vertical distributions. Makes sense?
Also, I'm sure you did it, but just in case: node alignment must only affect selected nodes (node selection only exists in the node edit context), not all nodes in the selected object.
Another thing I always wanted to have is Random distribution. Maybe you can add it while you're working on that dialog, I think it should be easy enough?
To do so, if it's not already here, I'll add a stdc::signal<void, ToolIdent> _tool_changed; for the desktop.
Yes, it will be very useful in other situations as well.
Yes. But as we will refactor all the dialogs, that should be the right time to do it. The only thing needed is to make each dialog inherit from a class.
That's a good idea, as currently there's much shared code that can be moved to the parent class (delete/destroy handlers, etc.). Some of the shared code is already factored out into dialog-events but not all.
is the impact on the GUI. Do we keep buttons for calling each dialog ? How much docker areas can you create? How do you create one ? What happens with keyboard shortcuts ?
I'm not sure about docker areas (never used them), but of course each dialog must remain a verb with its own button icon and shortcut, as they are now.
Multiple instances of the same dialog does not sound like a
good >idea
at all. I think it will be just confusing without any
advantage.
OK, so maybe a ctrl+shift+a shortcut could bring the align dialog in a new docker if it does not already exists. This way, you could still work as now, but w/ the ability to group several dialogs in one.
Yes, if the current behavior is more or less preserved (e.g. I can use the shortcut to open the dialog, or bring it to front if it's already open, and if the dialogs remember position/size) then I see no problem with them being dockable (if the dock sets are remembered too).
I was also wondering if we could split the fill dialog in 3 different dialogs, strarting in the same docker, but you could rearrange that, eg if you want to see in the same time fills and strokes ...
Yes, I thought about breaking it into Color dialog (two tabs) and Stroke dialog (single tab).
participants (2)
-
aubi＠...373... -
bulia byak