One dialog we'll likely need soon is the Layers. Ask Mental when he thinks the code will be ready for creating a UI.
As for the grid dialog, why separate dialog? Is it so big and complex it won't fit into the Grid tab of the current ctrl-shift-d dialog?
How about working towards a very stable release. I know that the Inkscape project has ambitious goals, much of which are in UI currently, but it really seems like we need to get some releases that tackle some of these massive bugs. Not every release has to be monumental, right?
I vote for 0.37 as the 'bugkiller' release.
Jon2
On Thu, 2003-11-27 at 13:33, bulia byak wrote:
One dialog we'll likely need soon is the Layers. Ask Mental when he thinks the code will be ready for creating a UI.
As for the grid dialog, why separate dialog? Is it so big and complex it won't fit into the Grid tab of the current ctrl-shift-d dialog?
On Thu, 27 Nov 2003, bulia byak wrote:
One dialog we'll likely need soon is the Layers. Ask Mental when he thinks the code will be ready for creating a UI.
Mental says it's ready now. "Yeah, doing the SPObject tree in gtkmm would be nice."
As for the grid dialog, why separate dialog? Is it so big and complex it won't fit into the Grid tab of the current ctrl-shift-d dialog?
No, it's because the dialog is highly dynamic, in that you can edit the grid layout dynamically by dragging control points around. Nathan had implemented it in Python initially and converting it directly to Gtkmm/C++ feels preferrable to him than figuring out how to do it in C/Gtk, if we plan on converting it to Gtkmm/C++ eventually anyway. This had originally been planned for 0.36 but Nathan decided to hold off on it until after we're committed to C++ for these reasons. Presumably we want to keep this in the ctrl-shift-d dialog so if we chose to do this one then we'd probably do the whole dialog.
So to recap, here's the proposed dialogs so far:
0. Redesign Desktop Settings Dialog. Rationale: Nathan wants to build on Gtkmm/C++ for his grid work. Downside: The new grid code isn't in the codebase yet.
1. New Layers Dialog. Rationale: Mental's work on layers is implemented but requires a dialog in order to actually use it. Downside: None I can think of.
2. Unified Object Properties Dialog. Rationale: We have a nice conceptual layout for this dialog, and it would clean up numerous other dialogs. It could also include layers, so would encapsulate #1 as well. Downside: Could be more work than the other options.
3. Redesign Color Dialog. Rationale: It's what Jon Cruz is working on and there might be some nice color support features in Gtkmm. Downside: The new color code isn't finished yet.
Hmm, it does look like the layer dialog (#1) would be a good place to start with Gtkmm. The underlying code's in place, and this wouldn't disrupt existing dialogs. Once that layer dialog is under our belts, then we'd be better prepared for creating the unified dialog (#2), and branching out to other dialogs.
Bryce
On Thu, 2003-11-27 at 17:32, Bryce Harrington wrote:
On Thu, 27 Nov 2003, bulia byak wrote:
One dialog we'll likely need soon is the Layers. Ask Mental when he thinks the code will be ready for creating a UI.
Mental says it's ready now. "Yeah, doing the SPObject tree in gtkmm would be nice."
Well, almost ready. I think there is some infrastructural work I would like to do first.
Namely, cleaning up the verb/action stuff so toolbox buttons/menu items/whatever are really bound to per-window actions.
Right now, all verbs/actions look at the "current document" when invoked and use that, regardless of what window they were attached to. We need to kill all these global state things, BAD.
-mental
bulia byak wrote:
As for the grid dialog, why separate dialog? Is it so big and complex it won't fit into the Grid tab of the current ctrl-shift-d dialog?
It's not big, in fact it is simpler. It's just that my changes mean that I have to restructure the grid representation and it would be easier to get right using C++, which is our planned language anyway. It's not a separate dialog, so in fact my first step will probably be to port the whole ctrl-shift-d dialog to gtkmm to get a feel for how things work.
Btw, I don't have close boxes on my dialogs (see attached png)
My window manager is sawfish (default).
njh
participants (5)
-
Bryce Harrington -
bulia byak -
Jonathan Phillips -
MenTaLguY -
Nathan Hurst