Re: [LMMS-devel] Scales and chords - better use other formulas?

[Tobias D. <tob...@gm...>]

Am Mittwoch, 10. Mai 2006 01:56 schrieb danny mcrae:
> > Apart from that I think lmms would improve if the
> > popup menu for the arp and chord widget would not
> > show one large list of possibilities but a
> > ordered list (submenus?)
> Submenus might not hurt.  The menu is already a bit
> too large to conveniently use on my rather low
> resolution laptop.
hm, if we'd make up the whole chord-table again, it would be no problem to =
add=20
information about the submenu, an item belongs to. I think you can figure=20
this out on your own and implement whatever you want ;-) The only thing I'm=
=20
going to do in this matter is giving CVS-access to Rob ;-)

> > 1) I use Qt4 to write my own applications but lmms
> > did not compile so I switched back to Qt3. What
> > should the code be focusing on as I seem to
> > get many #ifdef QT4 constructions in my code if I
> > want to write it for both libraries (for
> > example QString.split() is not Qt3, QVector is not
> > Qt3 etc. etc.).
> Qt3.3 support is a must at the moment.  We're also
> trying to provide support for Qt4 as well.  Toby did a
> lot of work a couple weeks ago at getting the Qt4
> support cleaned up.  All I know about Qt4 is that
> installing it turned out to be a quick way to screw up
> a Gentoo box.  I've been afraid of it ever since.
what the hell did you do with your Qt4-installation?! ;-) it's working fine=
 on=20
all distros out there I know... as it is currently a bit experimental, you=
=20
have to pass --with-qtdir to configure like

=2E/configure --with-qtdir=3D/usr/local/Trolltech/Qt-4.1.1/


> There are some typedefs in qt3support.h for spanning
> some of the API differences.
yeah, please have a look at it before writing a lot #ifdef QT4 etc. I know=
=20
this solution is not optimal and that many things could be done much easier=
,=20
but only supporting Qt4 is too early and not supporting Qt4 is outmoded ;-)=
 I=20
think we can drop Qt3-support at the end of this year. A further problem is=
,=20
that Qt4's new painting-system Arthur is nice, but SLOW as hell therefore t=
he=20
GUI of LMMS is slow too as it is quite complex and often contains thousands=
=20
of qobjects/qwidgets....

> src/lmms_single_source.cpp is bit of a mystery to me.
> Looks like it includes everything in src/, but I
> haven't actually verified that.
the goal of lmms_single_source.cpp is compiling all source-files of LMMS at=
=20
once which gives more optimized binary-code as the compiler always knows th=
e=20
whole context of all source and thus can optimize better. For developers I=
=20
advice to pass --disable-ssc (single-source-compiling) to configure, beause=
=20
otherwise each time you modify something, EVERYTHING is compiled again with=
in=20
lmms_single_source.cpp which takes quite a lot of time...

> Any custom pixmaps you want to use should be stored as
> a .png in data/themes/default.  All of the pngs in
> that folder get compiled into a resource file that is
> then accessed from the code through the embed
> namespace.
not quite... embedding png-data into binary is only used for plugins. All=20
application gfx is stored within $prefix/share/lmms/themes/default as it is=
=20
too much data to simply compile it into the binary. This way packagers can=
=20
split the LMMS-distribution into lmms and lmms-data (everything below=20
$prefix/share/lmms) while lmms-data is architecture-independent and must no=
t=20
be provided for each platform (important for distros like Debian)
Beside that it's of course correct to place all graphics in the mentioned=20
directory ;-)

toby