Re: Tabbed Usage
- From: Lars Clausen <lars raeder dk>
- To: discussions about usage and development of dia <dia-list gnome org>
- Subject: Re: Tabbed Usage
- Date: Sun, 15 Apr 2007 12:05:16 +0200
On Sun, 2007-04-15 at 01:18 -0500, Patrick Hallinan wrote:
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.
That'd probably be easier. What were you thinking of doing for the
layers dialog?
Hadn't thought about the two sets of menus. I guess we'd need a third
"File" menu that's a combination of the two current ones. Fortunately,
that should be easy with GtkAction.
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.
When it changes to be gimplike_ui, changing it on the fly would mean
assembling/disassembling the windows, changing the menubars and other
stuff. I'd rather have working code that can only change at startup
than unfinished/messy code that can change any time. Once we've ironed
out how the two interfaces differ and have that working, we can look
into changing on the fly.
-Lars
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]