|
Tab support as experimental feature in 1.3.4 ?
Hi Scott,
About two weeks ago, we talked a bit on IRC about adding tabs to
1.3.4. I'd like to bring up this topic again.
I think that it's a good occasion to add tabs. Mark the feature in
sawfish-ui as "(EXPERIMENTAL)" next to the check-box which enables it.
If enabled, current theme will be checked if it supports tabs,
if not - the user would be informed somehow to pick another theme. It
can be quite a rudimentary dialog box or prompt or whatever - it will
be experimental, after all.
The main point is to LET more people test it.
On a side note, uh.. do you think that you could modify mxflat theme
to be tab-enabled? That's my favourite theme for about 4 years ;-)
I'd feel really comfortable testing tabs without changing theme. And
also I know this theme quite well, so I'd know if something is a
theme-related problem or a tab-code problem. But this is much less
important than just adding tabs as experimental feature.
How do you feel about that? What do others think?
--
Janek Kozicki |
|
|
Re: Tab support as experimental feature in 1.3.4 ?
OK, after some talk on IRC we think it may be done in following way:
1. Scott will bzr push his tabs code into SVN trunk (with whole history)
so that will be a dozen or so of commits. All commits will be
subsequent to each other.
2. After it's committed, we will add a wiki patch page. So that we
will not lose track of any single patch. It will be marked as
[[Accepted for 1.3.4]]. The actual diff will written in the same
manner as in http://sawfish.wikia.com/wiki/L10n_update or
http://sawfish.wikia.com/wiki/Major_C-Part_Clean-Up3. since we still don't have a clear policy for naming files/directories
with Scott's tabs code - let Scott name them in a way which suits him
best. Then we will look at it and start constructive criticism :)
4. Same with tab-enabled themes
5. There will be a checkbox to enable tabs in sawfish-ui, marked
as EXPERIMENTAL feature.
Please don't hesitate to comment on this idea.
--
Janek Kozicki |
|
|
Re: Tab support as experimental feature in 1.3.4 ?
Janek Kozicki said: (by the date of Mon, 4 Aug 2008 23:54:53 +0200)
> 2. After it's committed, we will add a wiki patch page.
We will do this after, because this feature is intended for testing
as experimental in the release. And the normal wiki voting procedure
here is not enough IMHO.
--
Janek Kozicki |
|
|
Re: Tab support as experimental feature in 1.3.4 ?
On Mon, Aug 4, 2008 at 11:54 PM, Janek Kozicki < janek_listy@...> wrote:
> OK, after some talk on IRC we think it may be done in following way:
>
> 1. Scott will bzr push his tabs code into SVN trunk (with whole history)
> so that will be a dozen or so of commits. All commits will be
> subsequent to each other.
>
> 2. After it's committed, we will add a wiki patch page. So that we
> will not lose track of any single patch. It will be marked as
> [[Accepted for 1.3.4]]. The actual diff will written in the same
> manner as in http://sawfish.wikia.com/wiki/L10n_update or
> http://sawfish.wikia.com/wiki/Major_C-Part_Clean-Up>
> 3. since we still don't have a clear policy for naming files/directories
> with Scott's tabs code - let Scott name them in a way which suits him
> best. Then we will look at it and start constructive criticism :)
>
> 4. Same with tab-enabled themes
>
> 5. There will be a checkbox to enable tabs in sawfish-ui, marked
> as EXPERIMENTAL feature.
>
>
> Please don't hesitate to comment on this idea.
I haven't looked at the code so I can be way off, but as tabs are
theme dependents, could it be activated only when one choose a tabs
enabled theme?
Last time I've looked themes were treated with caution (IIRC "gaoled"
was the term used, at the end it's code that we are downloading and
running from untrusted sources) so probably doing it inside themes is
not feasible.
--
Andrea
|
|
Re: Tab support as experimental feature in 1.3.4 ?
Andrea Vettorello said: (by the date of Tue, 5 Aug 2008 09:48:25 +0200)
> > Please don't hesitate to comment on this idea.
>
> I haven't looked at the code so I can be way off, but as tabs are
> theme dependents, could it be activated only when one choose a tabs
> enabled theme?
yes, exactly. Maybe it wasn't clear, because I've sent multiple
emails answering to myself (too much to read - sorry).
Scott will need to add a theme tab-capability checking. And if the
user decides to enable checkbox with experimental feature, he will be
informed if the theme is not tab-capable. As you said - the checkbox
can be grayed out if wrong theme is chosen. Or a dialog window could
appear, or sth else.
> Last time I've looked themes were treated with caution (IIRC "gaoled"
> was the term used, at the end it's code that we are downloading and
> running from untrusted sources) so probably doing it inside themes is
> not feasible.
Tab code in sawfish will check themes tab-capability. Perhaps by
checking if some variables are defined and not nil. We don't want to
modify hundreds of already existing themes just to say that they
don't have tab support.
Alternatively (simplest solution perhaps) - a short list of themes
with tab support can be hardcoded inside sawfish. And sawfish will
recognize them by name. Such solution is not a long-term one, so it
will be changed in the future. But this feature is experimental, and
the current goal is to allow people to do some preliminary testing
and feedback.
best regards
--
Janek Kozicki |
|
|
Re: Tab support as experimental feature in 1.3.4 ?
On Tue, Aug 5, 2008 at 10:26 AM, Janek Kozicki <janek_listy@...> wrote:
Scott will need to add a theme tab-capability checking. And if the
user decides to enable checkbox with experimental feature, he will be
informed if the theme is not tab-capable. As you said - the checkbox
can be grayed out if wrong theme is chosen. Or a dialog window could
appear, or sth else.
Un-tabbed themes do still work even if the feature is enabled, no need to check for that (in fact, better to have it for testing).
Maybe it could be better and easier to just have the tab-compatible themes in a separate directory and only load this directory when the feature is enabled. When the feature is disabled, unload it and change to a default un-tabbed theme.
Maybe there also could be a default tabbed theme to change when the checkbox is activated.
|
|
Re: Tab support as experimental feature in 1.3.4 ?
On Tue, Aug 5, 2008 at 11:54 AM, Fernando <ferkiwi@...> wrote:
Maybe it could be better and easier to just have the tab-compatible themes in a separate directory and only load this directory when the feature is enabled. When the feature is disabled, unload it and change to a default un-tabbed theme.
Maybe there also could be a default tabbed theme to change when the checkbox is activated.
I mean.. for the period of testing. Once the feature is stable enough there will be no need for separating the themes. Untabbed themes still work with this feature, the only thing that they lack is "displaying" the tabs.
What I mean is that it maybe could be a good thing to not disallow the user to have a untabbed theme (tabs hidden) while still being able to switch the window and have the feature (even if he can't see the tabs).
|
|
Re: Tab support as experimental feature in 1.3.4 ?
* Janek Kozicki < janek_listy@...> wrote:
> I think that it's a good occasion to add tabs. Mark the feature
> in sawfish-ui as "(EXPERIMENTAL)" next to the check-box which
> enables it.
I may need some help getting things to show up in sawfish-ui, but
I'll know more when I get there. I have homework to do before
asking any useful questions.
> The main point is to LET more people test it.
Yup. I'll get changes in soon. I've already added one of the
themes, to work out the process.
> think that you could modify mxflat theme to be tab-enabled?
Sure. It might not happen immediately, but I suspect it won't be
very difficult. The only problem is ... where is mxflat? I
don't see it anywhere.
-- Scott
|
|
Re: Tab support as experimental feature in 1.3.4 ?
Am Dienstag, den 05.08.2008, 05:21 -0600 schrieb Scott Scriven:
* Janek Kozicki <janek_listy@...> wrote:
> I think that it's a good occasion to add tabs. Mark the feature
> in sawfish-ui as "(EXPERIMENTAL)" next to the check-box which
> enables it.
I may need some help getting things to show up in sawfish-ui, but
I'll know more when I get there. I have homework to do before
asking any useful questions.
> The main point is to LET more people test it.
Yup. I'll get changes in soon. I've already added one of the
themes, to work out the process.
I added it to the list of themes to install in themes/Makefile.in (r4259)
I know tab code is not shipped yet, but the theme works without it, too.
> think that you could modify mxflat theme to be tab-enabled?
Sure. It might not happen immediately, but I suspect it won't be
very difficult. The only problem is ... where is mxflat? I
don't see it anywhere.
Wee. That would be great!
-- Scott
Chris
|
|
Re: where is mxflat
|
|
Re: where is mxflat
|
|
Re: Tab support as experimental feature in 1.3.4 ? (mxflat into trunk?)
Scott Scriven said: (by the date of Tue, 5 Aug 2008 05:21:25 -0600)
> > think that you could modify mxflat theme to be tab-enabled?
>
> Sure. It might not happen immediately, but I suspect it won't be
> very difficult. The only problem is ... where is mxflat? I
> don't see it anywhere.
Oh, one thing. This in fact means that mxflat needs to be added to
sawfish trunk. It's GPLed, and last update was in 2003 (just checked).
If nobody has objections I'll add it.
--
Janek Kozicki |
|
|
Re: where is mxflat
Wow, what a great theme! I was planning to start hacking a tablet
friendly theme, but this is just
what I need (with the ability to configure the bunch of buttons to do
different things). I still like
the look of microGUI more, though ;)
--dmg
|
|
Re: where is mxflat
* Christopher Bratusek < nano-master@...> wrote:
> You'll find it here: http://freshmeat.net/projects/mxflat/Based on its screenshot...
http://c.fsdn.com/fm/screenshots/32704.pngI'm guessing it won't be easy after all. This is probably the
most complicated theme available. There are two issues to figure
out:
- With user-configurable buttons and positions and such, it may
be difficult to figure out where exactly the title area is...
So far, the position of the title area has been hard-coded
into the user's tab config, so the problem is getting the tab
code and the theme code to communicate.
- The title area has no visual edges, so I'd have to add
something to put between tabs. This would also end up on the
left and right edges of the overall title area; not just
between tabs. So, at least some visual changes are probably
needed, unless people prefer having no separator between tabs.
Both of these would be much easier if I knew more about sawfish's
lisp code. I'm kinda stumbling in the dark.
I also suspect that some other options will break, like the
ability to use non-centered titles.
-- Scott
|
|
Re: Tab support as experimental feature in 1.3.4 ?
* Janek Kozicki < janek_listy@...> wrote:
> Scott will need to add a theme tab-capability checking.
It's worth mentioning that regular themes work with tabbed
windowing. The problem is that it doesn't show any windows
except the topmost per group... and I think there may be an
issue with defining mouse bindings, but I forget if I fixed that
already.
Tabbed themes also work without tabbed windowing.
So, I don't think there's a huge need to separate the themes for
technical reasons. However, the user might like an easy way to
know which themes are tab-enabled.
> Alternatively (simplest solution perhaps) - a short list of
> themes with tab support can be hardcoded inside sawfish.
How about just putting "-tabbed" on the end of each compatible
theme name? The get-S-tabbed theme is already this way, and I
was thinking Toyberg should be Elberg-tabbed...
-- Scott
|
|
Re: Tab support as experimental feature in 1.3.4 ?
* Scott Scriven < sawfish-list@...> wrote:
> Tabbed themes also work without tabbed windowing.
Nope, nevermind. Untrue.
I set up a completely clean environment and the tab themes
stopped working. The reason is that the title is drawn into a
frame part called "tab" instead of "title", and it depends on the
tab code (instead of the theme) to calculate the size/position of
that part.
So, I'm not sure if this will work, but ... maybe I could give
the tabs a default size, defined in the theme, and override it
when tabbed windowing is enabled.
-- Scott
|
|
Re: Tab support as experimental feature in 1.3.4 ?
On Wed, Aug 6, 2008 at 10:43 AM, Scott Scriven <sawfish-list@...> wrote:
The reason is that the title is drawn into a
frame part called "tab" instead of "title", and it depends on the
tab code (instead of the theme) to calculate the size/position of
that part.
Why don't put a "title" part in tabbed themes too? along with the "tab" part, but being overlapped by the tabs when the tabs are showing.
I did it while checking the feature and it does work. The tab gets on top on the title when the feature is active, overlapping it. The bad thing is that only the active tab does get on top of the title, the inactive ones, however, do not show.
But that, I think, it's rather a bug, since inactive tabs should be in the same layer as the active. There are also other cases that make the inactive tabs be overlapped by other windows, all those things should be fixed somehow, and make all the tabs be drawn at the same time.
-- Fernando
|
|
Re: Tab support as experimental feature in 1.3.4 ?
Fernando said: (by the date of Wed, 6 Aug 2008 11:04:26 +0200)
> Why don't put a "title" part in tabbed themes too? along with the "tab"
> part, but being overlapped by the tabs when the tabs are showing.
> I did it while checking the feature and it does work.
how did you do that - can you share a patch? Maybe it will be helpful
for Scott?
--
Janek Kozicki |
|
|
Re: Tab support as experimental feature in 1.3.4 ? (mxflat into trunk?)
Janek Kozicki said: (by the date of Tue, 5 Aug 2008 17:34:27 +0200)
> If nobody has objections I'll add it.
(-: not me, but Chris. Thanks a lot.
--
Janek Kozicki |
|
|
Re: mxflat-tabbed
Scott Scriven said: (by the date of Tue, 5 Aug 2008 21:08:03 -0600)
> * Christopher Bratusek < nano-master@...> wrote:
> > You'll find it here: http://freshmeat.net/projects/mxflat/>
> Based on its screenshot...
>
> http://c.fsdn.com/fm/screenshots/32704.png>
> I'm guessing it won't be easy after all. This is probably the
> most complicated theme available. There are two issues to figure
> out:
>
> - With user-configurable buttons and positions and such, it may
> be difficult to figure out where exactly the title area is...
> So far, the position of the title area has been hard-coded
> into the user's tab config, so the problem is getting the tab
> code and the theme code to communicate.
Ouch. That may be a problem indeed. The tab code cannot read the
variables in a theme? (because they don't exist in not-tabbed themes?)
Fernando, do you have any idea how to do that?
I think that the best (and only?) solution is to ask theme about
that. it would be sth like a pixel position of tab-bar-start and |
signature.asc (204 bytes)