alt/title on images/links

[spirp]

Hi!

Just an idea - if alt/title-info, with the material name, is added for images and links in the DB, materials that have names that are to long for the grid layout would be visible anyways, when howering over a thumbnail for example.

For example, this one http://www.indigorenderer.com/joomla/in ... Itemid=107 only show up as "White_Exterio..." when browsing.

Also, while I'm at it, how about some sort of naming convention? So that names are kept specific and in the same form? At least, a simple rule to replace _ with " " would be nice

Thanks in advance, and for the DB!

// Olle

[fused]

i dont have much time to work on the matDB, thats for sure.

guess i won't mess with the mat names, but the thing with the alt/title info sounds good.

maybe i should make the matDB open source, so it can evolve (but that would lead to kerkythea and lux having matDBs soon, as they are using joomla, too. not sure if i want this ).

[spirp]

sound great - no probs with the naming stuff, I just suggested that while I was writing anyways take your time, and rest assured the db is appreciated as it is already!

and by the way - I'm all in for open source and so on - but in this case, h*ll no! don't give it away let indigo have the advantage with the db, so that all muppets who hasn't already tried indigo, have yet another reason to do so

// Olle

[pixie]

If you don't understand the spirit of Open Source you shouldn't release it. Open Source is about being cooperative not reinventing the well, maximizing workload, if they use your code they won't be using theirs, and they will be improving yours at no extra cost of money nor time.

Indigo competition is not Lux or kerkythea which are either free or open, indigo competition is first and foremost itself, then those who already walked the path (ie- comercial products), not those who share the same spirit of Indigo...

[fused]

oh, i do understand the spirit of open source.

maybe they'll improve it, but who says ill see only 1 line of it?

[spirp]

I'm more than familiar with "the spirit of Open Source" as well, and while I do agree with Fused, that there's no guarantees that he'll ever get anything back from the community, one could only hope that collaboration goes both ways.

Also, depending on the license, one could always prevent others from using the code for anything else but development purposes, in that way effectively stopping any unwanted use of the code. This on the other hand, is indeed a conflict with "the spirit of Open Source" pixie is talking about, but still - it would be Open Source - one must be very careful not to confuse Open Source for Free Software (free as in freedom, of course).

That said, I'd like to propose that this discussion - if necessary - is continued elsewhere, in a forum where this wouldn't be deemed off topic.

// Olle
[edited: fixed a typo]

[fused]

That said, I'd like to propose that this discussion - if necessary - is continued elsewhere, in a forum where this wouldn't be deemed off topic.

// Olle
[edited: fixed a typo]

hmm i thinks its just fine if its carried on here, as it is at least the right forum(if the topic stays "matDB os or not?").

[dougal2]

maybe i should make the matDB open source, so it can evolve (but that would lead to kerkythea and lux having matDBs soon, as they are using joomla, too. not sure if i want this ).

Fear not, Lux is getting it's own DB system - which has some quite specific needs and features so copying an existing system is not feasible. Also, it will not be a joomla plugin, but a standalone PHP site.
However, the Lux system will be open sourced when finished.

[pixie]

@dougal2:
Damn they're already one step ahead!

@spirp:

I'm more than familiar with "the spirit of Open Source" as well, and while I do agree with Fused, that there's no guarantees that he'll ever get anything back from the community, one could only hope that collaboration goes both ways.

There's no need for guarantee, it's in the open people or take advantage or they won't, either way indigodb won't cease to function, still as it's referenced the code is spread the brand is spread and it's a good thing.

[fused]

@dougal:

good, that makes it easier for me to release it as OS.

so your giving it another shot, i guess?
so, what makes you favour an standalone solution over a joomla component?

the joomla integration has some very obvious advantages.

edit: these are for example
- access to all joomla functions, the existing user system(including all rights and permissions, plus you dont need an extra reg/login)

[pixie]

@fused:
Interesting you bring the fact that some are using the Joomla and therefore present a risk, when Joomla itself is Open Source.

I know Joomla itself is GPL, I wonder just how derived code as being used on plugins should be treated...[/quote]

[dougal2]

so your giving it another shot, i guess?

yes, and it's going to be bigger and better than before

so, what makes you favour an standalone solution over a joomla component

A number of reasons:
1, the Lux site at the minute is joomla powered, but as far as I know it's not being used much as a CMS. In fact the site design is about to change.
2, currently all Lux online 'services' (forum, wiki, gallery, bugtracker) all require separate logins anyway, one more isn't going to make any difference.
3, All user management on the materials DB site is being handled by the framework I'm using (Kohana), and while that makes my job easier to get the thing up and running quickly, it'd be a royal PITA to integrate with an existing Users DB (but it could perhaps happen at a later date).
4, The framework I'm using provides an enormous number of libraries for various things, and is very easily extendable.

Th multiple logins problem perhaps a problem that needs addressing with Lux's online 'services', but it's not a problem I'm prepared to help solve right now.

[fused]

I know Joomla itself is GPL, I wonder just how derived code as being used on plugins should be treated...

Can I offer a hosted service with my custom, proprietary extensions?

Yes. The GNU GPL does not apply until you attempt to distribute your custom extensions to an outside party. If you decide to distribute your extensions, they will need to be licensed under the GNU GPL.

there you have it.

@dougal:

yes, thats reasonable. but make sure its not too bloated
keep in mind that a material database should only have two main functions: upload and download.

having lots of extras and fancy editors is cool, but shouldnt make the main functionality (as most user just want to download).

but thats just my oppinion.

corious to see what youll come up with!

[pixie]

There you have it Fused, the database is already GPLed, the only thing lacking is distributing... Although to me it seems that it's a bit 'unethical' to talk on the fear of having others using your code when yours is built on top of Opens Source Software.

[fused]

did you get the "The GNU GPL does not apply until you attempt to distribute" part?

its not GPLed because it is not distributed

and no i dont think its unethical. it is less the fear of someone else using the code(id be perfectly happy with that, actually id be proud of it), its more like indigo does have an advantage having a material database and that might get lost by open sourcing the database code.


you're a mac user, right? so you're telling me something about bulding on top of open source software and taking an advantage out of it?