Forums

Unfortunately no one can be told what FluxBB is - you have to see it for yourself.

You are not logged in.

#26 Re: Announcements » Discussion on 1.4 » 2009-07-12 22:44:45

elbekko

That was an excellent read, thanks for that! I'll see about implementing and testing it tomorrow.

#27 Re: Announcements » Discussion on 1.4 » 2009-07-12 13:09:59

elbekko
ridgerunner wrote:

In that spirit, I'll be offering some positive contributions shortly...

Great, that's the way I like it wink

#28 Re: Announcements » Discussion on 1.4 » 2009-07-11 15:00:15

elbekko
ridgerunner wrote:
elbekko wrote:

... I'd like to bring part of this discussion to the community. ...

And yet when they respond, you simply disregard their opinion because they obviously don't know what they are talking about! I may be new to the Pun/Flux development community, but I am certainly not new to programming. I've been working as a software engineer since 1981 and have a LOT of experience that you might just want to cultivate - including expertise in regular expressions which (from looking at the code), you guys could use some help with. As I said before, the first 2 (non-trivial) regexs I looked at in detail in the 1.3 parser have errors. I found no such errors in the 1.2 code (of the ones I looked at - but those aren't perfect either).

But it sounds like you have already made up your minds.

Feel free to post improvements then, instead of just saying "no, this can't possbily be good."
As for personally attacking me, I really don't give a damn, but it doesn't really make your opinion any more valid (quite the opposite, in fact).

#29 Re: Announcements » Discussion on 1.4 » 2009-07-11 12:48:27

elbekko
ridgerunner wrote:

I vote no.

For starters its feature creep and you promised this would not happen. And besides, the 1.2 parser code is smaller, cleaner and much more readable than 1.3, particularly with regard to the implementation of regular expressions (e.g. Just take a look at the preparse_bbcode() function for comparison). The few regexes that I took a close look at in the 1.3 parser were poorly written at best. (This is one of the main reasons I abandoned using 1.3). Note that the 1.3 parser has twice the bloat (28KB vs 14KB) and yet is poorly commented.

The 1.2 code is superior IMHO. Its not broken, don't fix it!

Yet it isn't. For 1.3 we worked on making the parser faster, as it was the biggest slowdown in the whole code. We're now porting it to 1.4 (which is nearly done) to provide this speed boost. What you think of the code and what it actually is are very different things obviously.
And I'd hardly call it feature creep if you're replacing instead of adding.

#30 Re: Core development » 2.0 Ideas » 2009-07-09 12:52:39

elbekko

I like the idea of modularity, but it brings a host of problems just like the extension system tongue

#31 Re: Core development » 1.4 beta 2 » 2009-07-06 00:08:47

elbekko

Making it just display the error rather than trying to fix that error should fix it.

#32 Re: Core development » Code tags in code tags » 2009-07-04 13:42:21

elbekko

I'm pretty sure that will be the case when we put the 1.3 parser in 1.4 tongue

#33 Re: Announcements » Discussion on 1.4 » 2009-07-04 13:41:08

elbekko

Yes, but as FSX said, there is also a slight issue with paragraphs that needs to be fixed. Still, the style changes would be very minor, and could probably be put in base.css so custom styles don't break.

#34 Re: Core development » 1.4 beta 2 » 2009-07-01 12:59:24

elbekko

The whole subscription thing does feel like a bit of feature creep to be honest, and would be much better suited for a modification for now.

#35 Re: Announcements » Discussion on 1.4 » 2009-07-01 12:54:23

elbekko

@Mpok:
Well, I don't see how a toolbar mod would break due to the inner workings of the parser changing. The BBCode won't change or anything, just how it is handled. Putting in the new parser is basically plug and play, and Paul has the code done already for a personal project.

Now, I can take a look at PunToolbar for you, but I have a feeling it won't break a thing. If it does, it's probably made in the wrong way tongue

@sirena:
I wouldn't call it feature creep, it's just a few thoughts we want the opinion of the community on wink As I said, it should be basically plug and play, so no code other than the parser would change.

#36 Announcements » Discussion on 1.4 » 2009-06-30 17:38:29

elbekko
Replies: 44

Right, since the next 1.4 release just might be close, us developers have been discussing a thing or two, and I'd like to bring part of this discussion to the community.

First up is the parser. We've been toying with the idea of implementing 1.3's parser in 1.4. It's cleaner, faster, and just overall better. The downside to this is that some minor style changes will need to be made, which may break user styles.
We'd really like your input on this smile

#37 Re: Core development » Question: 1.3 parser for 1.4 » 2009-06-29 17:47:51

elbekko

And here I thought the parser was already in 1.4. If it isn't, I think it's important enough to port it and break a bit of backwards compatibility (won't break much).

#38 Re: Programming » Database update question » 2009-06-29 11:58:19

elbekko

Well, the general consesus is usually 'let the database handle it', especially for constraints etc.
I'd go for the second case, you can always see if any rows were affected, so that isn't a reason to not do it this way either.

#39 Re: Feature requests » Can you move o_base_url to config.php » 2009-06-29 11:54:00

elbekko

For 1.3 we moved it, but that obviously won't happen for compatibility purposes in 1.4.

#41 Re: General discussion » Firefox 3.5 » 2009-06-28 19:32:43

elbekko

Waiting for the final, I just hope my extensions don't break.

#42 Re: Core development » Site update again » 2009-06-27 00:24:34

elbekko

That is very, very nice.

#43 Re: General discussion » IE8 » 2009-06-26 19:52:24

elbekko
Paul wrote:

Interestingly I just viewed a page I'm working on in Compatability mode then in IE7 mode using the developer tools. The rendering was different. It looked fine in compatability mode but in IE7 mode it required the usual "has layout" fix to work. In theory that means compatability mode is a waste of space for testing purposes because the page could still look wrong in IE7.

Did you try setting the browser mode to IE7 in the Developer Tools?

#44 Re: General discussion » IE8 » 2009-06-26 17:49:50

elbekko

Compatibility mode = IE7 mode (or worse).

So yes.

#45 Re: Core development » 1.4 beta 2 » 2009-06-21 13:47:10

elbekko

1.4 will replace 1.2, easy as that. I don't think there's any benefit in keeping 1.2 supported, apart from perhaps helping to port/rewrite popular mods for 1.2 to 1.4.

#46 Re: Feature requests » Facebook Connect plugin request » 2009-06-20 11:40:22

elbekko

And what exactly would this do?

#47 Core development » 1.4 beta 2 » 2009-06-18 17:24:58

elbekko
Replies: 35

Anyone got any suggestions for stuff that needs to be done still?

I've had a thought that I think could be rather handy: a script that consolidates all CSS files, minifies them and caches them in the style folder as <stylename>_min.css, while keeping the original CSS files for editing. This would reduce the number of requests and decrease output file size. It would be a rather minor change to 1.4 that doesn't break anything. There's the Minify project, already in PHP, that could probably be adapted to work with PHP4.

#48 Re: Feature requests » CSS: rearrangement and resize (was "Common style parts") » 2009-06-18 07:33:33

elbekko

What? I don't see how adding a file would be in any way beneficial.

If anything, I'd rather put it all together so not so many files need to be requested.

#49 Re: General discussion » Back... » 2009-06-13 11:37:51

elbekko

Awesome, good to have you back wink

#50 Re: Feature requests » Improved subscription » 2009-06-11 10:10:13

elbekko

What is this doing in Feature requests?
What version do you want to do this in?

Board footer

Powered by FluxBB 1.4.8