From: pete s. <zen...@ze...> - 2008-01-11 08:25:19
|
ey up a while back, Radoslaw wrote a patch that replaced the scroll bar with a scroll pane which displays that entire wave form in miniature, with the handle highlighted to show the visible view range. the patch used gtk_paint_box calls that drew themed widget parts and this caused some problems as the results can be unsuitable. (you get some proper funky scroll bars in themes) i've modified it slightly to use lower level gdk_draw_* functions. before i commit, i want to canvas for opinions. is it best to draw the active view section (which is the bar) with the sample display colours? eg: http://www.zenadsl6252.zen.co.uk/coloured-scroll-pane.png or to just swap the colours used for the trough, which are taken from the widget style. eg: http://www.zenadsl6252.zen.co.uk/swapped-bg-scroll-pane.png also, is everyone happy for this to replace the standard scrollbar entirely? Radoslaw, are you happy with these changes? cheers, pete. |
From: Erik de C. L. <ml...@me...> - 2008-01-11 08:41:06
|
pete shorthose wrote: > is it best to draw the active view section (which > is the bar) with the sample display colours? eg: > > http://www.zenadsl6252.zen.co.uk/coloured-scroll-pane.png I like that one better than this: > http://www.zenadsl6252.zen.co.uk/swapped-bg-scroll-pane.png > also, is everyone happy for this to replace the > standard scrollbar entirely? I like it. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "One serious obstacle to the adoption of good programming languages is the notion that everything has to be sacrificed for speed. In computer languages as in life, speed kills." -- Mike Vanier |
From: Conrad P. <co...@me...> - 2008-01-11 08:47:43
|
On 11/01/2008, pete shorthose <zen...@ze...> wrote: > i've modified it slightly to use lower level > gdk_draw_* functions. before i commit, i want to > canvas for opinions. > > is it best to draw the active view section (which > is the bar) with the sample display colours? eg: > > http://www.zenadsl6252.zen.co.uk/coloured-scroll-pane.png That screenshot seems to be using the black/white colour scheme anyway. How does it look for schemes with less contrast, like the yellow one? > or to just swap the colours used for the trough, > which are taken from the widget style. eg: > > http://www.zenadsl6252.zen.co.uk/swapped-bg-scroll-pane.png > also, is everyone happy for this to replace the > standard scrollbar entirely? looks pretty nice to me. The screenshots you posted seem to be zoomed to selection. How does it display otherwise, eg. if the selection is bigger or smaller than the current view? Conrad. |
From: pete s. <zen...@ze...> - 2008-01-11 10:15:36
|
On Fri, 11 Jan 2008 17:47:34 +0900 "Conrad Parker" <co...@me...> wrote: > On 11/01/2008, pete shorthose > <zen...@ze...> wrote: > > i've modified it slightly to use lower level > > gdk_draw_* functions. before i commit, i want > > to canvas for opinions. > > > > is it best to draw the active view section > > (which is the bar) with the sample display > > colours? eg: > > > > http://www.zenadsl6252.zen.co.uk/coloured-scroll-pane.png > > That screenshot seems to be using the > black/white colour scheme anyway. to be clear, there are no selections in either shot and the theme in use is Bluescreen. the bar only shows the active view range and selections are ignored (at the moment) > How does it > look for schemes with less contrast, like the > yellow one? http://www.zenadsl6252.zen.co.uk/lineup.png depends on the theme. for generic light themes the only scheme that doesn't work so well is blackwattle. but the handle bar does have a black box drawn around it so it's still visible. nevertheless, it's this drawback that prompted me to try (gtk) theme only colours. i also tried swapping fg and bg scheme colours to draw the hidden areas but it was pretty garish (black on bright green to green on black then back again anyone?) > > > or to just swap the colours used for the > > trough, which are taken from the widget > > style. eg: > > > > http://www.zenadsl6252.zen.co.uk/swapped-bg-scroll-pane.png > > > also, is everyone happy for this to replace > > the standard scrollbar entirely? > > looks pretty nice to me. > > The screenshots you posted seem to be zoomed to > selection. no selections but i want to indicate the selections on or around the scroll pane somehow. adding them as per the view range but with a different colour might make it too busy to be useful though. we can try things out tho. just for reference, it's easier to see how the colours are picked with this dark theme shot: http://www.zenadsl6252.zen.co.uk/dark-theme-example.png pete |
From: pete s. <zen...@ze...> - 2008-01-11 10:07:13
|
On Fri, 11 Jan 2008 19:40:56 +1100 Erik de Castro Lopo <ml...@me...> wrote: > pete shorthose wrote: > > > is it best to draw the active view section > > (which is the bar) with the sample display > > colours? eg: > > > > http://www.zenadsl6252.zen.co.uk/coloured-scroll-pane.png > > I like that one better than this: > > > http://www.zenadsl6252.zen.co.uk/swapped-bg-scroll-pane.png me too. but as you can see here: http://www.zenadsl6252.zen.co.uk/lineup.png not all schemes work so well with generic light gtk themes. pity, as i find the colour helps to differentiate the bar from the trough. it associates the context of the two widgets nicely too. pete |
From: Erik de C. L. <ml...@me...> - 2008-01-11 10:12:20
|
pete shorthose wrote: > me too. but as you can see here: > > http://www.zenadsl6252.zen.co.uk/lineup.png > > not all schemes work so well with generic light > gtk themes. Maybe for the themes with light backgrounds the bits of the scroll region which are outside the current viewing area should have a dark background. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "Reality is just a crutch for people that can't handle CyberSpace!!" - Hank Duderstadt |
From: <rad...@ko...> - 2008-01-11 10:34:45
|
MjAwOC8xLzExLCBwZXRlIHNob3J0aG9zZSA8emVuYWRzbDYyNTJAemVuLmNvLnVrPjoKPgo+IGV5 IHVwCj4KPiBhIHdoaWxlIGJhY2ssIFJhZG9zbGF3IHdyb3RlIGEgcGF0Y2ggdGhhdAo+IHJlcGxh Y2VkIHRoZSBzY3JvbGwgYmFyIHdpdGggYSBzY3JvbGwgcGFuZSB3aGljaAo+IGRpc3BsYXlzIHRo YXQgZW50aXJlIHdhdmUgZm9ybSBpbiBtaW5pYXR1cmUsIHdpdGgKPiB0aGUgaGFuZGxlIGhpZ2hs aWdodGVkIHRvIHNob3cgdGhlIHZpc2libGUKPiB2aWV3IHJhbmdlLiB0aGUgcGF0Y2ggdXNlZCBn dGtfcGFpbnRfYm94IGNhbGxzCj4gdGhhdCBkcmV3IHRoZW1lZCB3aWRnZXQgcGFydHMgYW5kIHRo aXMgY2F1c2VkIHNvbWUKPiBwcm9ibGVtcyBhcyB0aGUgcmVzdWx0cyBjYW4gYmUgdW5zdWl0YWJs ZS4gKHlvdQo+IGdldCBzb21lIHByb3BlciBmdW5reSBzY3JvbGwgYmFycyBpbiB0aGVtZXMpCgoK WWVzLCBpdHMgdHJ1ZS4KCmkndmUgbW9kaWZpZWQgaXQgc2xpZ2h0bHkgdG8gdXNlIGxvd2VyIGxl dmVsCj4gZ2RrX2RyYXdfKiBmdW5jdGlvbnMuIGJlZm9yZSBpIGNvbW1pdCwgaSB3YW50IHRvCj4g Y2FudmFzIGZvciBvcGluaW9ucy4KPgo+IGlzIGl0IGJlc3QgdG8gZHJhdyB0aGUgYWN0aXZlIHZp ZXcgc2VjdGlvbiAod2hpY2gKPiBpcyB0aGUgYmFyKSB3aXRoIHRoZSBzYW1wbGUgZGlzcGxheSBj b2xvdXJzPyBlZzoKCgpXZWxsLCB3aHkgbm90ISA6KQoKaHR0cDovL3d3dy56ZW5hZHNsNjI1Mi56 ZW4uY28udWsvY29sb3VyZWQtc2Nyb2xsLXBhbmUucG5nCj4KPiBvciB0byBqdXN0IHN3YXAgdGhl IGNvbG91cnMgdXNlZCBmb3IgdGhlIHRyb3VnaCwKPiB3aGljaCBhcmUgdGFrZW4gZnJvbSB0aGUg d2lkZ2V0IHN0eWxlLiBlZzoKPgo+IGh0dHA6Ly93d3cuemVuYWRzbDYyNTIuemVuLmNvLnVrL3N3 YXBwZWQtYmctc2Nyb2xsLXBhbmUucG5nCj4KPiBhbHNvLCBpcyBldmVyeW9uZSBoYXBweSBmb3Ig dGhpcyB0byByZXBsYWNlIHRoZQo+IHN0YW5kYXJkIHNjcm9sbGJhciBlbnRpcmVseT8KPgo+IFJh ZG9zbGF3LCBhcmUgeW91IGhhcHB5IHdpdGggdGhlc2UgY2hhbmdlcz8KCgpJdHMsIG9rIGZvciBt ZSwgYnV0IGhhdmUgaW4gbWluZCB0aGF0IGRpc3BsYXlfY2FjaGUgd2hpY2ggd29ya3MgYmVoaW5k CnNjcm9sbF9wYW5lIGlzbid0IGZ1bGx5IHN0YWJsZSBhbmQgY2FuIGNyYXNoIHN3ZWVwIC0gdmVy eSwgdmVyeSByYXJlbHkuCgpSYWRvc2xhdwoKLS0gClJhZG9zxYJhdyBLb3J6ZW5pZXdza2kKcmFk b3NsYXdAa29yemVuaWV3c2tpLm5ldAo= |
From: pete s. <zen...@ze...> - 2008-01-11 13:03:07
|
On Fri, 11 Jan 2008 11:34:39 +0100 "Radosław Korzeniewski" <rad...@ko...> wrote: > 2008/1/11, pete shorthose > <zen...@ze...>: > > Radoslaw, are you happy with these changes? > > > Its, ok for me, but have in mind that > display_cache which works behind scroll_pane > isn't fully stable and can crash sweep - very, > very rarely. i'm not using the cache patch. unless i missed something, the scroll pane patch references the data directly. eg: from scroll-pane.c: scroll_pane_draw_data_channel () d = ((sw_audio_t *)sample->sounddata->data)[i*channels + channel]; pete. |
From: <rad...@ko...> - 2008-01-11 14:53:16
|
MjAwOC8xLzExLCBwZXRlIHNob3J0aG9zZSA8emVuYWRzbDYyNTJAemVuLmNvLnVrPjoKPgo+ID4g PiBlZzogZnJvbSBzY3JvbGwtcGFuZS5jOgo+ID4gPiBzY3JvbGxfcGFuZV9kcmF3X2RhdGFfY2hh bm5lbCAoKQo+ID4gPgo+ID4gPiAgIGQgPSAoKHN3X2F1ZGlvX3QgKilzYW1wbGUtPnNvdW5kZGF0 YS0+ZGF0YSkKPiA+ID4gW2kqY2hhbm5lbHMgKyBjaGFubmVsXTsgb24KPiA+ID4KPiA+Cj4gPiBP Sywgc28gZ29vZCBuZXdzOiBpdCBzaG91bGQgYmUgc3RhYmxlLCBiYWQKPiA+IG5ld3M6IGl0IHNo b3VsZCBiZSBzbG93LiBUaGUgbWFpbiBwcm9ibGVtIGlzCj4gPiB0aGF0IHNjcm9vbGJhciByZWZy ZXNoIGFuZCByZWRyYXcKPiA+IChzY3JvbGxfcGFuZV9leHBvc2UpIGlzIGNhbGxlZCBldmVyeSB0 aW1lIHdpdGgKPiA+IGFsbCBzYW1wbGUgdG8gcmVkcmF3IGFuZCBpdCdzIGd0a19zY3Jvb2xiYXIK PiA+IGZlYXR1cmUuIFRoaXMgaXMgd2h5IEkgd2FzIHN0YXJ0aW5nIHRvIHdyaXRlCj4gPiBzYW1w bGUgY2FjaGUuCj4KPiBpIG1heSBoYXZlIG1pc3VuZGVyc3Rvb2Qgd2hhdCB5b3UgbWVhbnQgYnkg ZGlzcGxheQo+IGNhY2hlLiBpJ2xsIHRha2UgYSBsb29rIGF0IHRoYXQgcGF0Y2guCgoKTm8sIEkg dGhpbmsgWW91IGhhdmUgdW5kZXJzdG9vZCBpdCBjb3JyZWN0bHkuIERpc3BsYXlfY2FjaGUgaXMg bG9jYXRlZCBpbgpkaXNwbGF5X2NhY2hlLltjLGhdIGZpbGVzIGFuZCBkbyB0aGUgZm9sbG93aW5n IHRoaW5nczoKLSBjb21wdXRlIG1pbi9tYXgvYXZnL3JtcywgZXRjLgotIGNvbXB1dGUgc2luYy9v dGhlciBpbnRlcnBvbGF0aW9uICh1bmZpbmlzaGVkKQotIGNhY2hlIGFib3ZlIGNvbXB1dGF0aW9u cyBpbiBtZW1vcnkgKGhhcyBzb21lIGxpbWl0YXRpb25zKQotIChpbiBmdXR1cmUpIGNvbXB1dGUg RkZUCgphcmRvdXIgdXNlcyBzb21lIGZ1bmt5IG1hY3JvcyB0byBkbyB3YXZlIGRyYXdpbmcuCj4g cHJlc3VtYWJseSB0aGV5IGFyZSBmYXN0ZXIgc28gdGhhdCBtaWdodCBiZQo+IHNvbWV0aGluZyB0 byBsb29rIGludG8uCgoKR2VuZXJhbCBydWxlIGlzIHRvIGRyYXcgYW5kIGNvbXB1dGUgYXMgbWlu aW11bSBhcyBwb3NzaWJsZS4gV2l0aApkaXNwbGF5X2NhY2hlIHdlIGNhbiByZWR1Y2UgbnVtYmVy IG9mIGNvbXB1dGF0aW9ucywgd2l0aCBzbWFydCBiYWNraW5nIHN0b3JlCnBpeG1hcCB3ZSBjYW4g cmVkdWNlIG51bWJlciBvZiBkcmF3aW5ncy4KCmkgY2FuIGFsc28gZW5hYmxlIGJhY2tpbmcgc3Rv cmUgb24gYWxsCj4gd2lkZ2V0cyAoeGNvbmZpZyBwZXJtaXR0aW5nKSB0byBza2lwIGluY2lkZW50 YWwKPiBleHBvc2UgZXZlbnRzIHRvby4gYXNzdW1pbmcgaXQncyBzdWl0YWJsZSBmb3IKPiByYXBp ZGx5IHVwZGF0ZWQgd2luZG93cy4gKGkgdGhpbmsgcXQ0IGRvZXMgdGhpcwo+IG5vdykKCgpHb29k IHN0ZXAuCgppdCdzIHByZXR0eSBxdWljayBpbiBvcGVyYXRpb24gaGVyZSB0aG91Z2guIHA0Cj4g bW9iaWxlIDJnaWcgbGFwdG9wLiBoYXJkbHkgdGhlIHN0YXRlIG9mIHRoZSBhcnQuCj4KPiBwZXRl Lgo+CgpXZSBoYXZlIHRvIHJlbWVtYmVyIHRoYXQgY2Fpcm8gZHJhd2luZyBsaWJyYXJ5IGlzIHdh aXRpbmcgdG8gZ2V0IGZ1bGwKaGFyZHdhcmUgYWNjZWxlcmF0aW9uIGluIGd0ay4KCmNoZWVycwoK UmFkZWsKCi0tIApSYWRvc8WCYXcgS29yemVuaWV3c2tpCnJhZG9zbGF3QGtvcnplbmlld3NraS5u ZXQK |
From: pete s. <zen...@ze...> - 2008-01-12 05:47:14
|
On Fri, 11 Jan 2008 15:53:13 +0100 "Radosław Korzeniewski" <rad...@ko...> wrote: > 2008/1/11, pete shorthose > <zen...@ze...>: > > > > > > eg: from scroll-pane.c: > > > > scroll_pane_draw_data_channel () > > > > > > > > d = ((sw_audio_t *) > > > > sample->sounddata->data) [i*channels + > > > > channel]; on > > > > > > > > > > OK, so good news: it should be stable, bad > > > news: it should be slow. The main problem is > > > that scroolbar refresh and redraw > > > (scroll_pane_expose) is called every time > > > with all sample to redraw and it's > > > gtk_scroolbar feature. This is why I was > > > starting to write sample cache. GtkRange does a lot behind the scenes that is superfluous to our needs. the range rect dimensions are also sensitive to themes which we really don't want as we override the drawing operations completely now. i'll take a look and see if it's best to roll a bespoke widget or if we can get away with overriding some more of the widget functions. > it's pretty quick in operation here though. p4 > > mobile 2gig laptop. hardly the state of the > > art. > > > > pete. > > > > We have to remember that cairo drawing library > is waiting to get full hardware acceleration in > gtk. well, we aren't using cairo yet but i'm open to a menu option that switches between old and new scroll widgets. perhaps i'll wait till someone complains that sweep is too slow first. (and with the proviso that they aren't running it on an abacus) i intended to reply to the list too, sorry about that. pete |
From: <rad...@ko...> - 2008-01-12 10:42:47
|
On 2008-01-12, at 06:47, pete shorthose wrote: >> We have to remember that cairo drawing library >> is waiting to get full hardware acceleration in >> gtk. > > well, we aren't using cairo yet but i'm open to > a menu option that switches between old and new > scroll widgets. perhaps i'll wait till someone > complains that sweep is too slow first. > (and with the proviso that they aren't running > it on an abacus) We, aren't, but gtk is using. :) Back in time sweep had a great gui, now it's dated. Last major gui redesing was at Jan 18 2003 where sweep 0.8.0 was introduced. Its 5 years now. a lot of time. We should think about it. Radek |
From: pete s. <zen...@ze...> - 2008-01-12 13:31:52
|
On Sat, 12 Jan 2008 11:42:22 +0100 Radosław Korzeniewski <rad...@ko...> wrote: > > On 2008-01-12, at 06:47, pete shorthose wrote: > >> We have to remember that cairo drawing > >> library is waiting to get full hardware > >> acceleration in gtk. > > > > well, we aren't using cairo yet but i'm open > > to a menu option that switches between old > > and new scroll widgets. perhaps i'll wait > > till someone complains that sweep is too slow > > first. (and with the proviso that they aren't > > running it on an abacus) > > We, aren't, but gtk is using. :) for anything pertinent like gdk_draw_line() and friends? news to me if so. my beanie hat is at hand ready to be eaten.... hmmm tasty wool. :) > Back in time sweep had a great gui, now it's > dated. Last major gui redesing was at Jan 18 > 2003 where sweep 0.8.0 was introduced. Its 5 > years now. a lot of time. We should think about > it. the... grey... nnnnnnnggg and i used to love it so. iirc correctly, i spoke to Conrad about the general layout some time ago and he was happy with it. what changes did you have in mind? personally, i'd like to see additions (for new features) but mostly cosmetic changes otherwise. nuking the static styles is high on my list but that requires a new (outlined) icon set for the controls. also, the relief on the transport buttons is a distinctive feature of sweep but it doesn't look right with most contemporary themes. i dunno, if it were my app, you'd all be subjected to my own taste in eye candy, eg: http://www.zenadsl6252.zen.co.uk/sweep-eatmyblur.png but it's not, so Thorsten and his shaolin assassins of interface purity can sleep soundly :P i don't really want to see sweep assimilated by the borg tho either. pete. |
From: Conrad P. <co...@me...> - 2008-01-12 14:25:57
|
On 12/01/2008, pete shorthose <zen...@ze...> wrote: > > the... grey... nnnnnnnggg > > and i used to love it so. iirc correctly, i spoke > to Conrad about the general layout some time ago > and he was happy with it. that's a pretty general statement :-) I agree that it needs some updating. > what changes did you have in mind? > personally, i'd like to see additions (for new > features) but mostly cosmetic changes otherwise. > > nuking the static styles is high on my list but > that requires a new (outlined) icon set for the > controls. also, the relief on the transport > buttons is a distinctive feature of sweep but it > doesn't look right with most contemporary themes. > > i dunno, if it were my app, you'd all be subjected > to my own taste in eye candy, > eg: > http://www.zenadsl6252.zen.co.uk/sweep-eatmyblur.png That looks pretty elite, I especially like the reworked transport bar. The different sizes for the main buttons give a useful indicator that they are important, without forcing color clashes. The blur is a nice touch too ;-) K. |
From: pete s. <zen...@ze...> - 2008-01-12 16:29:22
|
On Sat, 12 Jan 2008 23:25:46 +0900 "Conrad Parker" <co...@me...> wrote: > On 12/01/2008, pete shorthose > <zen...@ze...> wrote: > > i dunno, if it were my app, you'd all be > > subjected to my own taste in eye candy, > > eg: > > http://www.zenadsl6252.zen.co.uk/sweep-eatmyblur.png > > That looks pretty elite, I especially like the > reworked transport bar. The different sizes for > the main buttons give a useful indicator that > they are important, without forcing color > clashes. thanks. at least, that transport bar layout should translate better to the gamut of gtk2 themes that could be used with it, if we only strip the static styles. i'm more interested in functional changes atm, but if anyone has any ideas etc for layouts or designs, throw them at the list then we can mull them over with a mind to doing something at some point. bbiab, i need to prepare my defenses for the coming onslaught of shaolin assassins. (all that quake wars wasn't a waste of time after all!) pete. |