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
9151
Features / Re: Ditching themes?
« on April 30th, 2011, 05:18 PM »
I'm not much of a fan of noob-friendly CSS editing, personally. Tempted to get rid of that editor in the admin area. As for allowing people to set default colors for a styling, hmm... I guess it's doable, but only through using CSS variables. It can be done, but really, I imagine it would complicate things for Wedge at compilation time. Maybe by allowing to override only the actual CSS variables in the code...
9152
Off-topic / Re: Least its not cranky here...
« on April 30th, 2011, 04:35 PM »
I don't know what's with the "Texan guy" but to me he's a guy with issues, and I don't have time to waste with people who have issues -- whether it be with me or something else.
During the time yall™ are flaming each other, there's more work being done on my side. Just sayin'. There's nothing like a freakishly huge to-do-list.
During the time yall™ are flaming each other, there's more work being done on my side. Just sayin'. There's nothing like a freakishly huge to-do-list.
9154
Features / Re: Ditching themes?
« on April 30th, 2011, 12:51 PM »
Well right now it's very easy to change using an add-type styling. Hello.
9155
Features / Re: Ditching themes?
« on April 30th, 2011, 11:38 AM »
Split topic into its own... Calling for advice.
9156
Off-topic / Re: Wedge official shirt?
« on April 30th, 2011, 10:29 AM »
The logo details were discussed in the logo topic. I'm sure Bloc has a large version of it...? Ideally it should be vectorized.
9157
Features / Re: New revs
« on April 29th, 2011, 04:31 PM »
rev 748 (useless commit except for Pete and others here :P)
(2 files +1, 9kb)
+ Added hook for plugins to automatically modify $browser right after it's been built. (Load.php)
+ Added 'tablet' entry to browser detection. It only detects the iPad for now. Hi Pete! (Load.php)
+ Added a tablet entry to the list of wireless devices that get their own icon in posts. (Post2.php, images/post/tablet.gif)
(2 files +1, 9kb)
+ Added hook for plugins to automatically modify $browser right after it's been built. (Load.php)
+ Added 'tablet' entry to browser detection. It only detects the iPad for now. Hi Pete! (Load.php)
+ Added a tablet entry to the list of wireless devices that get their own icon in posts. (Post2.php, images/post/tablet.gif)
9158
Features / Re: New revs
« on April 29th, 2011, 12:34 AM »
rev 747 (useless iPhone commit)
(1 file +1, 6kb)
+ Added a (temp?) iPhone icon and made sure to use the icon by default when posting from an iPhone or iPod Touch. (Post2.php, images/post/iphone.gif)
Note: tested on the demo site...
(1 file +1, 6kb)
+ Added a (temp?) iPhone icon and made sure to use the icon by default when posting from an iPhone or iPod Touch. (Post2.php, images/post/iphone.gif)
Note: tested on the demo site...
9159
Features / Re: New revs
« on April 28th, 2011, 10:39 PM »
rev 746 (useless IE fixin')
(2 files, 5kb)
! I don't remember why (or when) I did that, but I think it seemed important at the time. Reverted the 'nowrap' white-space rule to 'pre' for .bbc_code and .php_code, as it didn't work in IE7 and IE8. (index.css)
! IE8 screws up short messages with smileys. (index.ie8.css)
@ Note: I really don't remember... >_< The first occurrence of the change is when I changed the default styling from Wuthering to Warm... But apparently, Warm wasn't already stored in the SVN at that point. So it kinda comes out of nowhere... Please test a multi-line code tag in Firefox, Chrome and Safari if you're interested in making sure it keeps working...!
(2 files, 5kb)
! I don't remember why (or when) I did that, but I think it seemed important at the time. Reverted the 'nowrap' white-space rule to 'pre' for .bbc_code and .php_code, as it didn't work in IE7 and IE8. (index.css)
! IE8 screws up short messages with smileys. (index.ie8.css)
@ Note: I really don't remember... >_< The first occurrence of the change is when I changed the default styling from Wuthering to Warm... But apparently, Warm wasn't already stored in the SVN at that point. So it kinda comes out of nowhere... Please test a multi-line code tag in Firefox, Chrome and Safari if you're interested in making sure it keeps working...!
9160
Features / Re: New revs
« on April 28th, 2011, 06:58 PM »
rev 745 (so useless I forgot to post it here)
(3 files, 8kb)
! Fixed a bug where after quick editing a post, you couldn't quick edit it again without either reloading the page or quick editing and cancelling another post. (topic.js)
! The hide_prefixes variables is a global, so it shouldn't be declared as local. (topic.js)
- Removed optimize section from topic.js, as I'm starting to dislike the systematic use of this feature on variable names. (topic.js)
* Tags can be in HTML5 format inside XML as long as they're inside CDATA tags... (Xml.template.php)
* The $xml variable in the CSS parser is misleading. It's not a XML document we're building, just some regular, arbitrary, crawlable HTML soup. Renamed it to $tree. (Class-CSS.php)
(3 files, 8kb)
! Fixed a bug where after quick editing a post, you couldn't quick edit it again without either reloading the page or quick editing and cancelling another post. (topic.js)
! The hide_prefixes variables is a global, so it shouldn't be declared as local. (topic.js)
- Removed optimize section from topic.js, as I'm starting to dislike the systematic use of this feature on variable names. (topic.js)
* Tags can be in HTML5 format inside XML as long as they're inside CDATA tags... (Xml.template.php)
* The $xml variable in the CSS parser is misleading. It's not a XML document we're building, just some regular, arbitrary, crawlable HTML soup. Renamed it to $tree. (Class-CSS.php)
9161
Features / Re: New revs
« on April 28th, 2011, 03:39 PM »
rev 744 (useless not-so-useless commit.)
(24 files, 52kb)
* Hopefully finished converting the Media template to validate HTML5. (Media.template.php, Media language, ManageMedia language)
- Removed debug mode for auto-embedding. It probably had a point back when it wasn't as efficient as it is nowadays... If your embedding is slow, just disable a bunch of sites. (Aeva-Embed.php, ManageMedia language, Media language)
! Renamed aeva_* variables to embed_* in everything related to auto-embedding. Hopefully should work. Also renamed $context['media_disable'] to $context['disable_media_tag']. (db_aeva.php, Aeva-Embed.php, ManageMedia.php, ManageMedia3.php, Subs-Media.php, ManageMedia language)
+ Added a .bbc_pre class to emulate <pre> mode in spans. Did some fixing on other occurrences of <pre>. (index.css, install.sql, Load.php, Subs-BBC.php)
- Removed support for pre_include hook. I don't think it's the 'right' way of doing it. Also removed WEDGE_HOOK_SETTINGS, since there's actually no point in providing support for a deprecated way of adding hooks... I must have been drunk when I did that in rev 252. (Load.php, Subs.php)
+ Added file parameter in add_hook(). You can now specify the required source file directly in that call. Skip the php extension and make sure it's a relative path based on the Sources folder. (Subs.php, Credits.php, ManageSettings.php)
! Fixed URL trimmer. It didn't actually work until now... (install.sql, Subs-BBC.php, ManagePosts.php, Admin language)
* Spacinazi. (db_aeva.php, Subs-Exif.php, captcha-ledicons_anim.php, Aeva-ModCP.php, Aeva-Subs-Vital.php)
@ Note: I renamed the aeva_ variables to fix issues with settings not being saved (they were expecting media_ vars so I changed everything to embed_). Maybe I should have simply told Wedge to expected aeva_ vars, but it's too late to change my mind now... Hopefully if there's any error in my change list, it'll be found soon enough. Or at least faster than it took me to realize trim_url wasn't working... :whistle:
(24 files, 52kb)
* Hopefully finished converting the Media template to validate HTML5. (Media.template.php, Media language, ManageMedia language)
- Removed debug mode for auto-embedding. It probably had a point back when it wasn't as efficient as it is nowadays... If your embedding is slow, just disable a bunch of sites. (Aeva-Embed.php, ManageMedia language, Media language)
! Renamed aeva_* variables to embed_* in everything related to auto-embedding. Hopefully should work. Also renamed $context['media_disable'] to $context['disable_media_tag']. (db_aeva.php, Aeva-Embed.php, ManageMedia.php, ManageMedia3.php, Subs-Media.php, ManageMedia language)
+ Added a .bbc_pre class to emulate <pre> mode in spans. Did some fixing on other occurrences of <pre>. (index.css, install.sql, Load.php, Subs-BBC.php)
- Removed support for pre_include hook. I don't think it's the 'right' way of doing it. Also removed WEDGE_HOOK_SETTINGS, since there's actually no point in providing support for a deprecated way of adding hooks... I must have been drunk when I did that in rev 252. (Load.php, Subs.php)
+ Added file parameter in add_hook(). You can now specify the required source file directly in that call. Skip the php extension and make sure it's a relative path based on the Sources folder. (Subs.php, Credits.php, ManageSettings.php)
! Fixed URL trimmer. It didn't actually work until now... (install.sql, Subs-BBC.php, ManagePosts.php, Admin language)
* Spacinazi. (db_aeva.php, Subs-Exif.php, captcha-ledicons_anim.php, Aeva-ModCP.php, Aeva-Subs-Vital.php)
@ Note: I renamed the aeva_ variables to fix issues with settings not being saved (they were expecting media_ vars so I changed everything to embed_). Maybe I should have simply told Wedge to expected aeva_ vars, but it's too late to change my mind now... Hopefully if there's any error in my change list, it'll be found soon enough. Or at least faster than it took me to realize trim_url wasn't working... :whistle:
9162
Features / Re: Ditching themes?
« on April 27th, 2011, 08:05 PM »
I have no idea. I'm really unsure what to do with theme settings. I'd tend to ditch everything and just assume that if someone uses a custom theme, they'll rarely change it, and so there's no reason to have different values for something. When it comes to board-specific themes, let's be realistic here: the news fader never shows up anywhere else than on the homepage anyway. So it's no big deal...
Then again, do we ditch the theme system at all?
I'd like to have opinions from everyone...
I don't really see a 'bad' point, in that it's really about turning themes into stylings. i.e. I could add the ability for stylings to specify new template files. Of course it makes for a strange mix of CSS, JS, XML and PHP in the same folder, but (1) there's nothing preventing the themer to put most of their non-CSS files into another folder as long as they're properly linked, (2) I think most themes don't have a lot of extra files anyway.
Then again, do we ditch the theme system at all?
I'd like to have opinions from everyone...
I don't really see a 'bad' point, in that it's really about turning themes into stylings. i.e. I could add the ability for stylings to specify new template files. Of course it makes for a strange mix of CSS, JS, XML and PHP in the same folder, but (1) there's nothing preventing the themer to put most of their non-CSS files into another folder as long as they're properly linked, (2) I think most themes don't have a lot of extra files anyway.
9163
Features / Re: New revs
« on April 27th, 2011, 07:09 PM »
rev 743 (useless function removal commit.)
(7 files, 9kb)
- Removed stylesheet parameter from loadTemplate(). Instead, use add_css_file('myfile', true) to load extra CSS. This was only ever used to load admin.css in Moderation and Package areas, so it's not a big loss. As a note, the fatal parameter isn't used either, so it could go just the same. (Admin.php, Load.php, ModerationCenter.php, PackageGet.php, Packages.php)
- Removed wedge_add_css just the same. Wedge is really better off with only the main CSS being cached in its own file. Contextual files need to be in their own files. Next step: merge wedge_cache_css with add_css_file. They're like twins! (Class-Editor.php, Subs-Cache.php)
(7 files, 9kb)
- Removed stylesheet parameter from loadTemplate(). Instead, use add_css_file('myfile', true) to load extra CSS. This was only ever used to load admin.css in Moderation and Package areas, so it's not a big loss. As a note, the fatal parameter isn't used either, so it could go just the same. (Admin.php, Load.php, ModerationCenter.php, PackageGet.php, Packages.php)
- Removed wedge_add_css just the same. Wedge is really better off with only the main CSS being cached in its own file. Contextual files need to be in their own files. Next step: merge wedge_cache_css with add_css_file. They're like twins! (Class-Editor.php, Subs-Cache.php)
9164
Plugins / Re: Wedge + SMF Mods
« on April 27th, 2011, 04:21 PM »
The update philosophy in Wedge is simple: just upload the modified files...
That's pretty much the same philosophy as in Aeva Media, as you'll remember :)
That's pretty much the same philosophy as in Aeva Media, as you'll remember :)
9165
Features / Ditching themes? (+ CSS preparsing)
« on April 27th, 2011, 04:20 PM »
You know, I'm actually very tempted to ditch *themes* altogether...
I pretty much have the same view as Bloc on this matter. But I'm not the only one making decisions here, of course, and it's not a shared vision. I'm fine with it as long as I don't have to test my styling feature in other themes :niark:
At any rate, I would like to remove the "per theme" aspect of user settings, yes. Although I didn't know Bloc introduced special settings in his custom themes. Maybe this has a use in the end, then...?
I pretty much have the same view as Bloc on this matter. But I'm not the only one making decisions here, of course, and it's not a shared vision. I'm fine with it as long as I don't have to test my styling feature in other themes :niark:
At any rate, I would like to remove the "per theme" aspect of user settings, yes. Although I didn't know Bloc introduced special settings in his custom themes. Maybe this has a use in the end, then...?