Re: Tabbed Usage





On 4/14/07, Lars Clausen <lars raeder dk> wrote:
On Fri, 2007-04-13 at 14:11 -0500, Patrick Hallinan wrote:
> Lars said:
>
> >> + Tabbed organisation of open diagrams (Like Firefox's pages) and the
> >> toolbox window all being in one consolidated environment. If this is
> >> possible already can you please explain, how can I do this?
>
>
> > That is not currently possible, I'm afraid.  I'm loath to try to implement
> > such a thing myself, so it'll have to be based on what GTK offers.  What
> > I'd like is something like KDE's draggable subwindows, but possibly a
>
> > GtkNoteBook and the toolbox together in a window would be an alternative.
> > I'd like it to be user configurable in some other way than through
> > preferences, but that may be a little much.  Maybe the preferences setting
>
> > should be "Gimp-like UI" (menu on right mouse, loose windows) vs.
> > non-Gimp-like (menubar, one window with tabs).
>
> I was happy to find this.  I was thinking of something along these
> lines.  I just started looking at the code.  If someone could suggest
> an approach I could start working on this.  I was thinking of starting
> with a simple glade project and trying to make the Dia pieces loadable
> widgets but maybe it makes more sense to create an alternate UI that's
> integrated in the project.

Please don't use Glade.  The one piece of Glade-based UI we have is an
unmaintainable mess.  Besides, this functionality will be spread out
over the program to a large degree.

> It looks like I would start hacking in app_init():
>
> void app_init(int argc, char** argv) {
> /* ... */
>
>   prefs_init();
>
>   if (dia_is_interactive) {
>     if( dia_gimp_like_ui_interface_selected )
>
>       init_gimp_like_ui();
>     else
>       init_non_gimp_like_ui();
>
>
> Of course I don't have a clue about what kind of changes this would entail.

We already have a prefs setting use_menu_bar that determines if the
diagram window is in the right mouse button or a regular menu bar.  I
suggest you start by encapsulating that in a function gimp_like_ui(), so
it is isolated.  Then you'll also see where it gets used.

The current use_menu_bar setting is for new views; gimp/no-gimp UI
should be per-invocation, so for consistency new views should get the
menu bar setting from startup, not from the newest preferences, which
may have changed; the gimp_like_ui() function can hide that difference.
At the same time, the preference should move away from the new view
section in preferences.

At that point, new functionality would be easy to add, that's where your
above if-sentence comes in.  interface.c has most of the window setup
stuff.  Are you planning to do some kind of "docking" like newer gimp
versions, where things like layers dialog can fit in the same window as
the toolbox?

I guess I was thinking of expanding the toolbox window to encompass a notebook for diagram windows and have the diagram window menu integrated with the toolbox menu.  I spent a few hours today just poking through the code.  I think I want to build out some documentation of the current architecture/object interactions before I do much else.  I wasn't thinking at all about "docked" components.  Just about an integrated interface that contained all the pieces in a single window. 

I don't understand why you would want the use_menubar preference to be locked in at startup.  It seems like something that would not be hard to change even in a window that was already up. 




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]