Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
1996
Features / Re: One theme to rule them all?
« on January 14th, 2014, 11:10 AM »
'core' means 'the main point of interest in this folder list', so it works as a root folder.
'engine' means 'what makes Wedge tick', and it'd probably work better as a root folder (while 'backend' is just fine in 'core'), so I see you point.
And sorry, I meant sub-folder for base, not sub-sub-folder.
'engine' means 'what makes Wedge tick', and it'd probably work better as a root folder (while 'backend' is just fine in 'core'), so I see you point.
And sorry, I meant sub-folder for base, not sub-sub-folder.
1997
The Pub / Re: Name poll! For something useless! Yay!
« on January 14th, 2014, 11:07 AM »
I've updated the poll to allow you guys to vote for one or two options, instead of just one. This way you can just choose to 'eliminate' the option you like the least.
1998
The Pub / Re: Name poll! For something useless! Yay!
« on January 14th, 2014, 11:06 AM »
Yes, that was me. :P
I don't want to influence the poll votes because I have a personal preference (which is possibly unlike what you might think), but I'm not 100% sure yet, and I thought that maybe doing a poll could help me choose. I may not choose the most popular option (or I just might), but it's helping me set my thoughts straight.
Contrary to what I say in the poll title, it's something important for me to get right. If I get confused by folder names, it just makes common tasks harder for me. Ideally, I would keep /Sources and /Themes, and have /javascript, /languages and /skins inside /Themes, but it just doesn't make sense. Even my own personal comfort isn't enough to justify having skins as a sub-folder of the *.template.php folder. Themes are gone from Wedge, it needs to be made clear. Skins are here to stay, because they're better in every respect.
I don't want to influence the poll votes because I have a personal preference (which is possibly unlike what you might think), but I'm not 100% sure yet, and I thought that maybe doing a poll could help me choose. I may not choose the most popular option (or I just might), but it's helping me set my thoughts straight.
Contrary to what I say in the poll title, it's something important for me to get right. If I get confused by folder names, it just makes common tasks harder for me. Ideally, I would keep /Sources and /Themes, and have /javascript, /languages and /skins inside /Themes, but it just doesn't make sense. Even my own personal comfort isn't enough to justify having skins as a sub-folder of the *.template.php folder. Themes are gone from Wedge, it needs to be made clear. Skins are here to stay, because they're better in every respect.
1999
Features / Re: One theme to rule them all?
« on January 14th, 2014, 09:41 AM »
I prefer to go through non-tech dictionaries for things like that, these are too limited... ;)
Anyway:
http://wedge.org/pub/8336/name-poll-for-something-useless-yay/
Anyway:
http://wedge.org/pub/8336/name-poll-for-something-useless-yay/
2000
The Pub / Name poll! For something useless! Yay!
« on January 14th, 2014, 09:38 AM »
They need to follow each other alphabetically.
2001
Features / Re: One theme to rule them all?
« on January 14th, 2014, 08:12 AM »
Perhaps I'm hesitating simply because I want to get it right for myself, not for others.
If I can't live with my changes, I can always redo them later, but it's at the cost of annoying more people.
The only alternatives I have for now is:
sources -> engine (this one, I'm very happy with)
templates -> html, interface (I can't believe I didn't come up with 'html' until now, ahem..!)
Again, I need a word that conveys the idea of visuals, or interaction (another word in 'i', hmm...), or frontend as defined above anyway.
If I can't live with my changes, I can always redo them later, but it's at the cost of annoying more people.
The only alternatives I have for now is:
sources -> engine (this one, I'm very happy with)
templates -> html, interface (I can't believe I didn't come up with 'html' until now, ahem..!)
Again, I need a word that conveys the idea of visuals, or interaction (another word in 'i', hmm...), or frontend as defined above anyway.
2002
Features / Re: One theme to rule them all?
« on January 14th, 2014, 12:58 AM »
@Pentaxian, it would sound silly to have a sub-sub-folder that's called 'base'.
Re: caps, last week I lowercased all of Wedge's folders, precisely for consistency. I prefer them lowercased generally. As for files, they're still named like in SMF, so that's DoneThisWay. I'm used to this. If I change anything more, I really won't be able to find my mark anymore, and I might as well switch to Elkarte, whose main problem for me is the completely different (shall I say somewhat obtuse...) folder structure. I don't want to mess with Wedge's.
Re: backend/frontend, I think that my main concern is that for years, I've advertised the fact that Pete was the backend guy, while I was the frontend guy. To me, frontend was what people were seeing when they browsed a forum (i.e. all 'public'-facing pages), while backend was the admin area. It works as a definition, but it's not the same as the new definition -- backend is all PHP files that handle requests and gather data, while frontend is all PHP, CSS and JS files that are used in the creation of the final HTML, using the data injected into them by the backend files. They're both valid definitions, I'm just concerned about the fact that I've switched from one to the other, and it doesn't make much sense to do that. On the other hand, I couldn't find anything better.
I like the word 'engine' better for Sources (rather than backend), but that leaves me with the need to find a counter-offer name for Themes (aka templates), that would not be 'frontend' (because it doesn't counter 'engine' but 'backend'), and would be sorted alphabetically after 'engine' ('exsomething'..?), but before 'javascript'... Which leaves us with words starting with F, G, H and I, and a few other words after 'ENG' and before 'JAV'.
So, basically, you all have 4 letters and a half to determine a good name for the folder that will contain *.template.php files... If you accept this challenge... Get started now! I'll mark your test papers tomorrow. :P If I don't get any suggestions I'm excited with, then I'll stick with backend and frontend.
Re: caps, last week I lowercased all of Wedge's folders, precisely for consistency. I prefer them lowercased generally. As for files, they're still named like in SMF, so that's DoneThisWay. I'm used to this. If I change anything more, I really won't be able to find my mark anymore, and I might as well switch to Elkarte, whose main problem for me is the completely different (shall I say somewhat obtuse...) folder structure. I don't want to mess with Wedge's.
Re: backend/frontend, I think that my main concern is that for years, I've advertised the fact that Pete was the backend guy, while I was the frontend guy. To me, frontend was what people were seeing when they browsed a forum (i.e. all 'public'-facing pages), while backend was the admin area. It works as a definition, but it's not the same as the new definition -- backend is all PHP files that handle requests and gather data, while frontend is all PHP, CSS and JS files that are used in the creation of the final HTML, using the data injected into them by the backend files. They're both valid definitions, I'm just concerned about the fact that I've switched from one to the other, and it doesn't make much sense to do that. On the other hand, I couldn't find anything better.
I like the word 'engine' better for Sources (rather than backend), but that leaves me with the need to find a counter-offer name for Themes (aka templates), that would not be 'frontend' (because it doesn't counter 'engine' but 'backend'), and would be sorted alphabetically after 'engine' ('exsomething'..?), but before 'javascript'... Which leaves us with words starting with F, G, H and I, and a few other words after 'ENG' and before 'JAV'.
So, basically, you all have 4 letters and a half to determine a good name for the folder that will contain *.template.php files... If you accept this challenge... Get started now! I'll mark your test papers tomorrow. :P If I don't get any suggestions I'm excited with, then I'll stick with backend and frontend.
2003
Plugins / Re: Lang. files?
« on January 14th, 2014, 12:22 AM »
@Farjo, because then translators only need to check the languages repo for any changes, they don't have to subscribe to notifications for the Wedge repo just to do their (unpaid!) job.Quote from ftab4me on January 13th, 2014, 08:27 PM Again-- languages can still be put into the same folder. (In fact, right now, it's the only way to add a language -- you FTP the files to the languages root folder.)
There are separate folders in the languages repo to make it easier to handle language files for both translators and users. They download the language repo, then they extract the language files from the folder they want, into their languages folder's root.
I'm only putting the French language files at the root alongside English files because I'm the author, and I don't want the hassle of entering two folders to update my site by FTP, instead of just one.Quote from ftab4me on January 13th, 2014, 08:27 PM Plugin language files are expected to remain in the plugin's personal folder. There's a language call (loadPluginLanguage) that replaces loadLanguage, and takes the plugin's ID into account to find the location of the language files. This is as designed by Arantor; I don't see any reason to change that. (Not taking into account the fact that I'm left the only maintainer of the plugin system now, and I've never actually used it, so that'll be a lot of fun[1]. The other two people who were making plugins for Wedge left this place some time ago, possibly because of real-life duties, or simply because they chose to go back to SMF too, I don't know, I'm no longer at SMF.)
I think you should have at the languages in the same folder. It makes things in the long run a hell of a lot easier.
There are separate folders in the languages repo to make it easier to handle language files for both translators and users. They download the language repo, then they extract the language files from the folder they want, into their languages folder's root.
I'm only putting the French language files at the root alongside English files because I'm the author, and I don't want the hassle of entering two folders to update my site by FTP, instead of just one.
Think about it for a minute, you have a new translation, you ftp it to the Languages folder and it instantly becomes available for use by Wedge just like English, English-UK and French. Also for any mods, all language files are in the one directory were authors do not have to add or remember directory names for each language.
| 1. | Which is why I'm in early plans of restoring some kind of SMF mod functionality in that you'll be able to modify source files like a regular mod, BUT it won't break your website if done incorrectly. I'll talk about that later. |
2004
Features / Re: One theme to rule them all?
« on January 13th, 2014, 06:56 PM »
@Pandos, that's basically what's in the Wedge repo before my last couple of commits that modified everything...
@Norodo> I have many words to replace the Sources folder ('app' is a good suggestion though, I like that), but nothing much for the Themes (templates) folder...
Currently, I'm trying out this combination: sources becomes 'backend', and templates becomes 'frontend'. (I don't like these words, but they're easy to understand for native speakers, I suppose. It's all part of the MVC thingy.)
However, it suddenly makes more sense to have languages, skins and javascript inside the 'frontend' folder as well, in which case I'd suddenly have to move everything down one level.
/core
/backend <-- *.php
/frontend <-- *.template.php
/javascript <-- *.js
/languages <-- *.english.php
/skins <-- *.css
Perhaps 'backend' and 'frontend' would work best as root folders, but then they'd have to share their space with 'assets' (fine by me), 'cache' (okay, becomes harder...), and 'css' and 'js', which starts getting messy. (Not even counting media and plugins...)
I like having two separate areas of the Wedge folder base: one area for files that shan't be modified by Wedge itself (with the exception of Aeva-Sites.php, and yes it does make sense to rewrite this one and store sites in the database to be cached later, but whatever...)
I like the word 'engine' more than 'backend', but if I'm going to use 'frontend', it makes more sense to use 'backend' for sources.
Also, apparently 'backend' and 'frontend' need a space before 'end', so, to English native speakers here -- does it bother you that I'm not putting a space or dash..? Or should I add a dash, at least?
Bump... Still hoping to release ASAP ;)
@Norodo> I have many words to replace the Sources folder ('app' is a good suggestion though, I like that), but nothing much for the Themes (templates) folder...
Currently, I'm trying out this combination: sources becomes 'backend', and templates becomes 'frontend'. (I don't like these words, but they're easy to understand for native speakers, I suppose. It's all part of the MVC thingy.)
However, it suddenly makes more sense to have languages, skins and javascript inside the 'frontend' folder as well, in which case I'd suddenly have to move everything down one level.
/core
/backend <-- *.php
/frontend <-- *.template.php
/javascript <-- *.js
/languages <-- *.english.php
/skins <-- *.css
Perhaps 'backend' and 'frontend' would work best as root folders, but then they'd have to share their space with 'assets' (fine by me), 'cache' (okay, becomes harder...), and 'css' and 'js', which starts getting messy. (Not even counting media and plugins...)
I like having two separate areas of the Wedge folder base: one area for files that shan't be modified by Wedge itself (with the exception of Aeva-Sites.php, and yes it does make sense to rewrite this one and store sites in the database to be cached later, but whatever...)
I like the word 'engine' more than 'backend', but if I'm going to use 'frontend', it makes more sense to use 'backend' for sources.
Also, apparently 'backend' and 'frontend' need a space before 'end', so, to English native speakers here -- does it bother you that I'm not putting a space or dash..? Or should I add a dash, at least?
Posted: January 13th, 2014, 01:19 PM
Bump... Still hoping to release ASAP ;)
2005
Plugins / Re: Lang. files?
« on January 13th, 2014, 01:08 PM »
Re: my question, I decided that French didn't really justify being included in the main repo. I mean, who here speaks French, apart from me..??!
I'm not going to bother everyone with my stuff.
I'm still leaving French at the root of the languages repo, but it will no longer be in the Wedge repo.
So, basically, I have a /core/languages/ folder, which contains only the *.english.php files in the Wedge repo, but on my local repo, it also contains French files, because my /core/languages folder is also a copy of my languages repo. See what I mean..? It just means that everytime I'll make a change to the English files, I'll have it in a 'committable' state for both the Wedge and languages repos. So, from now on, English changes will be exactly duplicated between Wedge and languages repos, taking a bit more space, but making it easier to quickly generate a 'working' zip of Wedge.
I'm not going to bother everyone with my stuff.
I'm still leaving French at the root of the languages repo, but it will no longer be in the Wedge repo.
So, basically, I have a /core/languages/ folder, which contains only the *.english.php files in the Wedge repo, but on my local repo, it also contains French files, because my /core/languages folder is also a copy of my languages repo. See what I mean..? It just means that everytime I'll make a change to the English files, I'll have it in a 'committable' state for both the Wedge and languages repos. So, from now on, English changes will be exactly duplicated between Wedge and languages repos, taking a bit more space, but making it easier to quickly generate a 'working' zip of Wedge.
2006
Plugins / Re: Lang. files?
« on January 13th, 2014, 01:00 PM »
Not for now; but there's the last blog post where you can start a reply or something, then if needed, I'll move it to a new topic, and then eventually (if Wedge gets any success), to its own board.
2007
Features / Re: One theme to rule them all?
« on January 13th, 2014, 12:46 AM »
And this last one, I really need to get right... I need help for folder names!
I need to fine a folder name for what used to be the 'Sources' folder. It contains, of course, all the main PHP files that power Wedge.
The new name needs to:
- show up before 'languages' in the folder list, and even preferably before 'javascript'. So, it needs to start with a letter between 'A' and 'L' at best, or 'A' and 'I' at worst.
- Reflect the fact that it contains PHP files, or Source files, or things that power the software.
I consider 'code' but it's too close to 'core'.
I also considered 'engine', but maybe it's a bit over the top for that folder.
Anything else, guys..? Don't forget you'll be updating that folder quite often, so might as well help in finding its name... ;)
I'm also trying to determine if I can push 'skins' (the CSS folders) after 'templates' (the theme folder with *.template.php files) in the folder list. That means either renaming 'skins' to something that's after 'T' in the alphabet ('visuals'? Meh...), or pushing 'templates' to something that's before 'S' in the alphabet. Unfortunately, I don't even have a basic idea for that one.
As a reminder, I'm planning to release the first Wedge public alpha this week, and the source code could be online as early as January 15. As such, having the final names for these folders is important to me. The order in the folder list is also important to me, because I'm used to documenting my changelogs following the 'natural' SMF order: Source files are documented first, then templates, then languages, scripts and skins. Changing the folder structure unfortunately changed the current order to scripts, languages, skins, source files, and templates.
I need to fine a folder name for what used to be the 'Sources' folder. It contains, of course, all the main PHP files that power Wedge.
The new name needs to:
- show up before 'languages' in the folder list, and even preferably before 'javascript'. So, it needs to start with a letter between 'A' and 'L' at best, or 'A' and 'I' at worst.
- Reflect the fact that it contains PHP files, or Source files, or things that power the software.
I consider 'code' but it's too close to 'core'.
I also considered 'engine', but maybe it's a bit over the top for that folder.
Anything else, guys..? Don't forget you'll be updating that folder quite often, so might as well help in finding its name... ;)
I'm also trying to determine if I can push 'skins' (the CSS folders) after 'templates' (the theme folder with *.template.php files) in the folder list. That means either renaming 'skins' to something that's after 'T' in the alphabet ('visuals'? Meh...), or pushing 'templates' to something that's before 'S' in the alphabet. Unfortunately, I don't even have a basic idea for that one.
As a reminder, I'm planning to release the first Wedge public alpha this week, and the source code could be online as early as January 15. As such, having the final names for these folders is important to me. The order in the folder list is also important to me, because I'm used to documenting my changelogs following the 'natural' SMF order: Source files are documented first, then templates, then languages, scripts and skins. Changing the folder structure unfortunately changed the current order to scripts, languages, skins, source files, and templates.
2008
The Pub / Re: git rebase is a joke...
« on January 13th, 2014, 12:36 AM »
The 'other' folder is gone entirely, in the end. It didn't make sense to keep it, especially as the entirety of it went into the stash history.
The 'languages' folders are all gone, except for /core/languages/, introduced recently. See the 'lang files' topic for a related question to users experienced with either github and/or git submodules. Thanks!
Amusingly, after all this cleanup, the repo size is now twice the original size, even after a git gc --prune=now, but I suspect it's down to the fact that my other (unpushed) branches are all based upon older versions of my history, meaning git is forced to keep a backup of all previous commits, too. Anyone knows how I could reintegrate the updated master into the other branches? I fear rebasing would end up in failure, but I guess it's the 'easiest' solution. But I don't even know if it's possible to take the master history, rebase another branch's tip on top of it, and then save that new stuff to a new branch (or the original feature branch)..?
I just want to make sure the Wedge repo is 100% solid before I push it to github, of course.
The 'languages' folders are all gone, except for /core/languages/, introduced recently. See the 'lang files' topic for a related question to users experienced with either github and/or git submodules. Thanks!
Amusingly, after all this cleanup, the repo size is now twice the original size, even after a git gc --prune=now, but I suspect it's down to the fact that my other (unpushed) branches are all based upon older versions of my history, meaning git is forced to keep a backup of all previous commits, too. Anyone knows how I could reintegrate the updated master into the other branches? I fear rebasing would end up in failure, but I guess it's the 'easiest' solution. But I don't even know if it's possible to take the master history, rebase another branch's tip on top of it, and then save that new stuff to a new branch (or the original feature branch)..?
I just want to make sure the Wedge repo is 100% solid before I push it to github, of course.
2009
Plugins / Re: Lang. files?
« on January 13th, 2014, 12:23 AM »
So, here's the current structure...
In the Wedge repo:
(root)
/core
/languages
- all English files
- all French files (<-- might possibly go.)
In the languages repo:
(root)
- all English files
- all French files
/english-uk
- all English UK files
/german
- all German files
Basically, whenever I make a change to an English file, I'd commit it to both the Wedge repo and languages repo, so that a Wedge package can easily be made out of the repo.
This causes the issue that, technically, it's a waste of repo space to duplicate these files. I was thinking of going for a submodule system for language folders, but I think there are issues with keeping both repos in sync, and whether Github can include the external repo in any automatically generated zip files..?
Anyone got experience with this..?
In the Wedge repo:
(root)
/core
/languages
- all English files
- all French files (<-- might possibly go.)
In the languages repo:
(root)
- all English files
- all French files
/english-uk
- all English UK files
/german
- all German files
Basically, whenever I make a change to an English file, I'd commit it to both the Wedge repo and languages repo, so that a Wedge package can easily be made out of the repo.
This causes the issue that, technically, it's a waste of repo space to duplicate these files. I was thinking of going for a submodule system for language folders, but I think there are issues with keeping both repos in sync, and whether Github can include the external repo in any automatically generated zip files..?
Anyone got experience with this..?
2010
Features / Re: One theme to rule them all?
« on January 12th, 2014, 01:07 PM »Ah! So the full folder structure is something like:
I guess I need to do some homework on skins / themes / templates (I thought they were just different names for the same thing).
Themes = a set of Templates, and their associated CSS and JavaScript files (SMF-only)
Variants = a set of CSS files that can replace the default CSS files in a particular theme. Consider them as CSS-only sub-themes. (SMF-only)
Skins = these are Wedge-specific, and started as a supercharged version of variants (replacing them immediately), and then gradually getting upgraded to finally get the power of themes, so they now also replace themes altogether. There's still 'one' theme, as the topic's name suggests, but since it's unique, I removed all code pertaining to supporting multiple themes. And that was a lot of code, really.
A theme's structure is:
Templates
CSS files
JS files
image files
A skin's structure is:
Skin definition (optional) + CSS files (optional) + skeleton (optional)
Replacement templates (optional)
Replacement languages (optional, and not implemented yet.)
The skin definition allows you to specify more JS and CSS files to load, too. Even external stuff. It's an XML file with dozens of options, and they're all detailed in skins\Warm\skin.xml, if you want to study them. (Once the repo is out, although I think you have read access to the BitBucket repo, anyway..? If you don't, feel free to ask, but the repo will be moved to Github this week anyway, so...[1])
You could rename core to weave, because you want to use the name and because it'll confuse people :)
Oh, while I'm at it -- I recently decided that I'll drop the 'idea' of starting all Wedge official skin names with a 'w'. It's not that I'm planning to release dozens of skins, or that I fear I won't find any more interesting names in 'w', it's just that I certainly don't like restraining myself to a very, very limited subset of the English language when it comes to naming things I've worked on very hard, eh.
| 1. | Possibly duplicated on BitBucket, too. I have yet to determine which will be the final resting place for the public repo; while Github is a much more popular website, I still like BitBucket's design more, and if the GH repo doesn't get any popular, then there's no reason to stick to Github. |