SiBaz

About me:
Email:

Send private message

You must be logged in to send a private message.

Pages

Activity

  • SiBaz posted on SiBaz's message board
  • SiBaz joined the group Plugin Development
  • SiBaz replied on the discussion topic SVN vs git on github in the group Feedback and Planning
    We're thinking about switching from SVN to git hosted by github.  Any community thoughts on this?
    • As a side, yet related, note, has any of you looked into the Atlassian suite (http://www.atlassian.com/)?  We purchased it for work about a year ago and have been very pleased. They have a free license for open source projects (http://www.atlassian.com/opensource/).

      Just an idea to be filed away under "options".

    • @Ed It's been upgraded to the latest version of Trac.  GUI-wise, this doesn't change much.  I actually quite like trac's GUI, and the other point you brought up are a matter of core team / community involvement, which as I hope is clear we're improving.

      What I'm going to do in the not-too-distant future is set up mirroring SVN to github to let people unsure about git have a try...

    • As it wassaid before - main problem and task isn't technological issude, but methodological. Without appropriatechanging of development model (if it's needed) changing only SCM will do less than nothing:

      1. Branch merging works nice in SVN, if developer don't forget mantra "Merge ofteb, merge fast"

      2. Chaos of partially-finished brances in any DCVS give us all one more headache - "Where is the best branch for me?"

      3. As mentioned also - why even don't see at Mercurial (well-designed, smartly-implemented), which I see as a better choice in DCVS world vs Git (which was born as a mix of "home-made code" Perl+shell+...)

      DCVS in coomon plays welll in situation of

      1. a lot of developers,

      2. which implements unrelated and independent changes

      10-15 authors (with community-commiters) isn't a big problem for well-organized work with "classic" VCS

  • SiBaz replied on the discussion topic What are YOUR site plugins? in the group Feedback and Planning
    What plugins do you use and love and cant live without and you'd love the Elgg 1.6 core team to take note of? If the Plugin you like needs to be in a certain order, please state that as well and put a link to the plugin page. Please keep it like...
    • On http://www.BrainDash.com/community/, we use a number of plugins.  Some we've written ourselves, some we've obtained from the community.  Our own plugins, CoReg and AutoLogin provide us with a single sign on.  friend_request makes friends a 2 way thing, rather than the default (which is more like 'fans' than friends) and sticky_widgets means I can, as an administrator pretty much control what profiles look like.  That's hugely important as I may well disable some widget plugins and replace them with different ones and I don't want users to see the dreaded broken plugin widget. 

      I've also written a few proprietory plugins which aren't available to the community, BD_Terms which changes certain core terms in the languages pages, that has to be the first plugin.  BD_Groups, which provides XML-RPC and XML interfaces to groups, BD_Scores which adds a widget to profiles to show your scores on our Third Party Site and BD_theme, which changes the stylesheet and a lot of the elgg view's to look like its part of www.braindash.com.

    • I'll let you know when I have a week spare. -.-

      adultslike.me uses so many plugins and I don't really think we could do without any of them. I've modified most of them in some ways, though, so the functionality (either backend or frontend) is different to most other sites...

      I have a folder crammed full of diff files so I can keep pace when there are updates to be had.

      It's almost a nightmare. Except I enjoy it. :|

      However, back to the topic...

      vazco's topbar plugin is probably the most useful. By far. It's allowed me to use elgg's builtin features - groups, pages - to a degree I wouldn't otherwise. 

      I also love izap_videos, tidypics, and autodash. :)

      I'll come back and add links when I have more time, if needed.

  • SiBaz replied on the discussion topic CSS Fixes in 1.6 RC1 in the group Feedback and Planning
    Is in 1.6 RC1 anything done on the css of Elgg? Or on the supplied mods? There are a lot of fixes that need to be done. For example the blog css isn't using any of the standard available styles in the core css. I can go on, but my main...
    • I think this could be worth discussing. I've seen a few cases of plugins in the full elgg distribution where the custom styles in each mod are duplicating styles that are set in the core css file. It would be nice to see a more consistent style driven from the core, so someone who isn't a css expert could subtly change the core theme without breaking the overall look and feel. Someone with better css skills probably should be able to handle the additional complication of changing the plugin styles on a more ad-hoc basis.

      Although from what i've seen over the last few releases everything is getting better and better

      Also one example of fix i've personally made to my theme's css (that overrides the core - that's i've been meaning to send to pete) is:

       

      .input-checkboxes {

          background-color: #252525;

          border-color:#252525;

      }

       

      .contentWrapper, .input-checkboxes {

          background-color: #1C1C1C;

          border-color:#1C1C1C;

      }

       

      .input-radio {

          background-color: #252525;

          border-color:#252525;

      }

       

      .contentWrapper, .input-radio {

          background-color: #1C1C1C;

          border-color:#1C1C1C;

      }

      This is a small basic change which lets IE6 correctly set the background colour of checkboxes and radio buttons (please don't get me started on how much I dislike IE6, but a lot of my users still use it), but it's just a small example of how small changes & feedback over time can improve consistency for all users.

    • It looks to me as though the original way of doing things was to have a single css.php file, whereas subsequently that method has evolved to have separate css.php pages for each plugin. What has never happened (by the looks of it) is breaking up the original css.php page, to populate the core plugins. 

      I would suggest, with heinsight, that the best option would be to have the core classes in the main css.php page, and each plugin just define the ones that relate to that. 

      As an extension of that, there could be more attention paid to inheriting classes from the base, rather than redefining them, so that subsequent changes to the style wouldn't require quite so much work. 

      I've attempted to do that in my own copy, by placing PHP variables in various places, then defining them centrally, so that the styles can change quickly and easily, but to do it properly is a lot of work.  If anyone want's to volunteer, great, otherwise I think we just need to ensure new stuff follows the new style and leave the old stuff alone.

      Simon

    • Related trac ticket: https://trac.elgg.org/elgg/ticket/952

      I agree with Don. The current core css makes it difficult to write a plugin without writing custom css. There are very few elements that are generic that can be used. This then makes it difficult to write themes since every plugin has it's own css.

      I'd like to see the core css at least define a set of primitives and then have plugin authors encouraged to use them.

  • SiBaz replied on the discussion topic CSS Fixes in 1.6 RC1 in the group Feedback and Planning
    Is in 1.6 RC1 anything done on the css of Elgg? Or on the supplied mods? There are a lot of fixes that need to be done. For example the blog css isn't using any of the standard available styles in the core css. I can go on, but my main...
    • I think this could be worth discussing. I've seen a few cases of plugins in the full elgg distribution where the custom styles in each mod are duplicating styles that are set in the core css file. It would be nice to see a more consistent style driven from the core, so someone who isn't a css expert could subtly change the core theme without breaking the overall look and feel. Someone with better css skills probably should be able to handle the additional complication of changing the plugin styles on a more ad-hoc basis.

      Although from what i've seen over the last few releases everything is getting better and better

      Also one example of fix i've personally made to my theme's css (that overrides the core - that's i've been meaning to send to pete) is:

       

      .input-checkboxes {

          background-color: #252525;

          border-color:#252525;

      }

       

      .contentWrapper, .input-checkboxes {

          background-color: #1C1C1C;

          border-color:#1C1C1C;

      }

       

      .input-radio {

          background-color: #252525;

          border-color:#252525;

      }

       

      .contentWrapper, .input-radio {

          background-color: #1C1C1C;

          border-color:#1C1C1C;

      }

      This is a small basic change which lets IE6 correctly set the background colour of checkboxes and radio buttons (please don't get me started on how much I dislike IE6, but a lot of my users still use it), but it's just a small example of how small changes & feedback over time can improve consistency for all users.

    • It looks to me as though the original way of doing things was to have a single css.php file, whereas subsequently that method has evolved to have separate css.php pages for each plugin. What has never happened (by the looks of it) is breaking up the original css.php page, to populate the core plugins. 

      I would suggest, with heinsight, that the best option would be to have the core classes in the main css.php page, and each plugin just define the ones that relate to that. 

      As an extension of that, there could be more attention paid to inheriting classes from the base, rather than redefining them, so that subsequent changes to the style wouldn't require quite so much work. 

      I've attempted to do that in my own copy, by placing PHP variables in various places, then defining them centrally, so that the styles can change quickly and easily, but to do it properly is a lot of work.  If anyone want's to volunteer, great, otherwise I think we just need to ensure new stuff follows the new style and leave the old stuff alone.

      Simon

    • Related trac ticket: https://trac.elgg.org/elgg/ticket/952

      I agree with Don. The current core css makes it difficult to write a plugin without writing custom css. There are very few elements that are generic that can be used. This then makes it difficult to write themes since every plugin has it's own css.

      I'd like to see the core css at least define a set of primitives and then have plugin authors encouraged to use them.

  • SiBaz replied on the discussion topic Community themes / plugins interface in the group Feedback and Planning
    We in the very early stages of creating a new themes/plugin system for the community site.  Our initial thoughts were that themes and plugins should be housed in a space something closer to a group than it is now.  Ideas...
  • SiBaz replied on the discussion topic Features which community developers have already added in the group Feedback and Planning
    I expect that most of the developers on here have written code, in their own fork's of core.  I thought it would be a good idea, if we had a discussion so the Core developers could get some idea of what could be put back into the community,...
    • I've written 2 patches, one to make simplecache use a subdirectory of HTTP_HOST within the data directory, and one to allow code in settings.php to add a prefix, after the site prefix, to the core entitiy tables.  So whereas normally entities, users_entity and sites_entity normally get prefixed with something like 'elgg' to give elggentities, elggusers_entity and elggsites_entity, on my system, depending on vhost, that becomes something different.  So I have elggbdsites_entity on one site and elggeqsites_entity on another.  That allows me to virtualise my instance of elgg. 

  • SiBaz added a new discussion topic Features which community developers have already added in the group Feedback and Planning
    I expect that most of the developers on here have written code, in their own fork's of core.  I thought it would be a good idea, if we had a discussion so the Core developers could get some idea of what could be put back into the community,...
    • I've written 2 patches, one to make simplecache use a subdirectory of HTTP_HOST within the data directory, and one to allow code in settings.php to add a prefix, after the site prefix, to the core entitiy tables.  So whereas normally entities, users_entity and sites_entity normally get prefixed with something like 'elgg' to give elggentities, elggusers_entity and elggsites_entity, on my system, depending on vhost, that becomes something different.  So I have elggbdsites_entity on one site and elggeqsites_entity on another.  That allows me to virtualise my instance of elgg. 

  • SiBaz added a new discussion topic Plugins which should be standard in the group Feedback and Planning
    There are a few plugins which are part of the community, but which really ought to be integrated into Elgg Full, as they are pretty standard.  I'm thinking particularly of Friend Requests and Sticky Widgets (rather than default widgets)
  • SiBaz joined the group Feedback and Planning
  • SiBaz joined the group Feedback and Planning

Group membership

  • Feedback and Planning

    Feedback and Planning

    Discussions about the past, present, and future of Elgg and this community site.
  • Professional Services

    Professional Services

    Get / offer professional help on Elgg; like customization, design, development, setup, hosting... Illegal trades are not allowed.
  • Plugin Development

    Plugin Development

    Talking about how to write plugins