GNU Rocket icon
category: general [glöplog]
stop bullying magic! it's not funny anymore!!
magic man to the rescue!
Just thought I'd update:
I've made an icon that I'm pleased enough with. It's a cheesy web 2.0 wannabe glossy icon thingie, but works well at all required sizes:
svg version
I've made an icon that I'm pleased enough with. It's a cheesy web 2.0 wannabe glossy icon thingie, but works well at all required sizes:
svg version
sorry, what is it called a rocket when it is some sort of a midi controller for demos? is this supposed to be a long running joke?
It was supposed to be called "Rockit" (as in "rock it"), but since the people involved are morons they misspelled it :)
yeah, put "gnu rocket" in google and read the description at:
http://rocket.sourceforge.net/
9 out of 10 people wouldn't get the "joke" and go away (I was one of them, I had to be convinced by gloom that this not about rockets and whatnots) :-)
http://rocket.sourceforge.net/
9 out of 10 people wouldn't get the "joke" and go away (I was one of them, I had to be convinced by gloom that this not about rockets and whatnots) :-)
Navis: Actually, the reason for the name is a coincidence/joke. Together with some other people we'd started a joke project (called GNU Rocket) on sourceforge (back in 2002 or something) to see how long obvious joke-projects survived without ever submitting anything useful. Fast forward some years, when skrebbel and I was discussing releasing our sync-tracker publicly, we figured that just reusing that old sourceforge project was faster and easier than setting up a new one. And as a result, the sync-tracker got a name.
Navis: Yeah, that description kicks ass! :D I've been considering updating the copyright-comments in the sources to attribute the copyright to GNU Rocket Foundation instead of me and skrebbel :)
it would be awesome with a small sample for opengl+bass.
Rasmus: Is there a good reason why that would be useful? The only thing that GNU Rocket really integrates with is the sound-API, and there's an example for BASS. I'm not really striving to be everybody's favorite boiler-plate code provider ;)
But if you're interested in porting example_bass to OpenGL (+GLFW or something) instead of D3D9, that would probably be useful now that bass is useful on non-Windows platforms. I'd accept such a patch ;)
But if you're interested in porting example_bass to OpenGL (+GLFW or something) instead of D3D9, that would probably be useful now that bass is useful on non-Windows platforms. I'd accept such a patch ;)
if i do that, i expect some one to buy me a beer at solskogen/revision party :)
rasmus: If that means you'll buy me a beer for every patch I've written, sure :)
i don't go buying bill gates beers for all his patches :-)
so, i've compiled an sdl/opengl/bass version of example_bass. how do i get it into the editor etc? :-)
ah nevermind. it works now.
Good to hear :)
Nice! Would you mind sending this as a patch in an e-mail to rocket-developers@lists.sf.net? I'm asking since I don't quite know what version you used as a base, so it's a bit tricky to get an accurate diff that I can apply. I can tell that it's not from the bleeding-edge (as of two days ago or something), since it doesn't call sync_destroy_device() at shutdown...
btw. would it be possible to collapse/expand rows in the editor sharing same prefix?
e.g. when exploded:
clear.r clear.g clear.b
e.g. when collapsed:
clear [+]
? :-)
e.g. when exploded:
clear.r clear.g clear.b
e.g. when collapsed:
clear [+]
? :-)
Not as it stands now, the gui-code is currently very insistent of each track being completely independent of each other (they can be freely moved etc) and there being a linear relation between the tracks and their screen-position. This is something that I think would make sense to change, but it would probably result in a quite large change.
At the same time I'm considering moving the GUI-code to Qt, and I wonder if something like that might make more sense as part of a larger Qt-rewrite.
There's also another (related) major UI-overhaul I want to do; track-group-tabs. That is, a tabbed view of different track-groups. There'd be one default tab that contains all tracks, and then the user could create tabs that tracks could be added to. That way, you can make a part-centric tab, which would be very useful. I tend to have 50-100 tracks for each demo, so it gets a bit tricky to find the right track quickly some times.
At the same time I'm considering moving the GUI-code to Qt, and I wonder if something like that might make more sense as part of a larger Qt-rewrite.
There's also another (related) major UI-overhaul I want to do; track-group-tabs. That is, a tabbed view of different track-groups. There'd be one default tab that contains all tracks, and then the user could create tabs that tracks could be added to. That way, you can make a part-centric tab, which would be very useful. I tend to have 50-100 tracks for each demo, so it gets a bit tricky to find the right track quickly some times.
ok, the tabs would do the trick for me
The tabs would reduce the need to be able to collapse, but I still think collapsing is an interesting idea and will keep it on my list of nice-to-have features.
perhaps an option to hide stuff? i.e. select a range of columns and hide them like excel.
As a GNU Rocket power-user, I can safely say that using tab to move around goes surprisingly fast. I would rather have a differentiation between global rows (like: part selectors, flashing and such) and rows that are tied to a specific part.
gloom, that could be handled via either my collapsing or by kusmas tabs :-)
i.e. either prefix the columns (part1.foo.bar) or move the columns to part1-tab, part2-tab, global-tab, etc.
i.e. either prefix the columns (part1.foo.bar) or move the columns to part1-tab, part2-tab, global-tab, etc.