Re: [IMPORTANT] Proposed Goals for next release - 1.3.6 or 1.5.0?
- From: Christopher Bratusek <nano-master gmx de>
- To: General discussion about sawfish wm <sawfish-list gnome org>
- Subject: Re: [IMPORTANT] Proposed Goals for next release - 1.3.6 or 1.5.0?
- Date: Mon, 29 Dec 2008 20:22:50 +0100
Am Montag, den 29.12.2008, 15:21 +0200 schrieb Timo Korvola:
Christopher Bratusek <nano-master gmx de> writes:
> For example when you use GEdit for editing HTML Code and
> need an color-picker for getting #xxxxx color-codes,
> you would have to switch between both windows all the time, instead you
> merge the color-picker into GEdit's frame an have both
> available in the same frame and can access them at the same time.
It remains unclear to me how merged windows are supposed to be managed
inside the frame. Will they be overlapping windows with internal
frames like Windows MDI? Or something else like tiled or tabbed?
John refers to the Mac as an example but I am unfamiliar with that.
If we implement alternative window management methods such as tiling
or tabbing inside these container frames, some people might want to
use those alternative methods for the top level, sort of emulating
Ion. Should they be able to? At least it seems that the feature
proposed here and tabbed windows should share quite a bit of code, as
both provide the capability to combine windows inside a single frame.
Implementing an alternative window management policy is likely to
involve quite a bit of work, as John also noted. Tabbing is fairly
easy, but tiling is already rather complicated: the user should be
able to reconfigure the layout and resize the parts. Focus policy
also requires some thinking.
let's say you got three windows, like that:
[frame]
window a
[frame]
[frame] window b
window c
now you merge them
[frame]
window a window c
window b
Either way, after re-thinking, I came to the conclusion, if the "raise-tab-on-hover" feature will finally work,
this would become obsolete, 'cause:
a) all windows are in the same frame when tabbing
b) with "raise-tab-on-hover" they can almost be accessed as same as fast as if they would be displayed at once
So, I'll remove "support for merging blah" from proposed goals.
Any news from Scott regarding Tab-support? I tried contacting him 3 weeks ago, but he didn't answer ... Can you try it?
(There are some probs with my mail-provider's server, it blocks several mail-addresses, Johns mail-address is one for example,
he had to mail me from work, to give me full access to librep and rep-gtk, perhaps Scott got the same problem when trying to
contact me?) If he doesn't respond again, I guess we'll have to implement tab-support on our own. We may use that updated and
improved version, that has been posted in the ML before. ... I'll look for the link and give it to you.
... and one more thing: Sawfish does not fully support EMWH spec, not much is missing, but it seems that this small portion causes
several problems (_NET_WM_USER_TIME which was added to 1.3.5 fixed such an issue, for example). Do you think you could have
a look at this? That would be great.
Chris
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]