Page layouts and tables

Serge D

Joined: 2009-06-11
Posts: 2466

Posted: Fri, 2009-06-12 14:16

Hi,

First, a Great Job with a new version! Very easy conversion from 2.x.

Few things I see as very important before final release:

* Please do not use tables anywhere (<TABLE>). It is harder to manage via CSS. It does not buy you much other then easier block structures. Example is a metadata block. Try to put a big description there.
* We need some sort of HTML tags support in descriptions
* Can Free Tiny-MCE editor be added by default for any editing needs? http://tinymce.moxiecode.com/
* Some clean up is required for current default CSS - "reset" CSS resets too much.
* Would be nice to define sidebars like it is done in WordPress

bharat

Joined: 2002-05-21
Posts: 7994

Posted: Sun, 2009-06-14 01:58

We use tables sparingly, but there are times when they make sense. Like on the admin/modules page. If you'd like to help us get rid of the existing tables we'd be happy to take the help. Create a fork on GitHub and start hacking on it and we'll pull your contributions into the main codebase when we've got it right.

We will be adding HTML support to descriptions and other fields (http://sourceforge.net/apps/trac/gallery/ticket/400)

We may eventually add something like TinyMCE, but it's not a focus for the 3.0 release.

I'll point our UI guys at this thread to look into the reset issue

I suspect we're going to do something similar to wordpress's sidebar approach, if we can figure out a simple way to do it.

---
Problems? Check gallery3/var/logs before you post! and file bugs here!
Latest code/upgrading: http://codex.gallery2.org/Gallery3:Upgrading
Latest git: http://codex.gallery2.org/Gallery:Using_Git

Serge D

Joined: 2009-06-11
Posts: 2466

Posted: Sun, 2009-06-14 05:09

Thank you for follow up.

I have no problem with tables in admin module, because the customization for it may be easier and information to display is limited. But when it comes to the gallery layout, flexibility is very important.
I have migrated from G2 to G3 without problems, but limits now introduced within basic sidebar blocks makes appearance not very nice. I am still in process of creating a new theme (header, menu, basic colors), but you can see progress here http://photo.dragonsoft.us/index.php/california.
You will notice that description in the sidebar makes it scroll. It is either that or cutoff text since table used just goes off the DIV. I will try to follow your suggestion though.

I am looking forward to Beta 2 for HTML support.

As far as sidebar blocks. You have the solution already - it works for dashboard - Easy and simple.
Put it under "appearance" with page showing selector and sidebar modules (no content, just names)
I would imagine that block settings could be exposed at some point, but it is not as important for this release.
Ability to select blocks from available, and order them would be enough.

Serge D

Joined: 2009-06-11
Posts: 2466

Posted: Thu, 2009-06-18 21:43

bharat wrote:

We use tables sparingly, but there are times when they make sense. Like on the admin/modules page. If you'd like to help us get rid of the existing tables we'd be happy to take the help. Create a fork on GitHub and start hacking on it and we'll pull your contributions into the main codebase when we've got it right.

There goes the sample: http://photo.dragonsoft.us/index.php/california

Changes:

Quote:

info_block.html.php
<?php defined("SYSPATH") or die("No direct script access.") ?>

<div class="title">
<div class="caption"><?= t("Title:") ?></div>
<div><?= p::clean($item->title) ?></div>
</div>
<? if ($item->description): ?>
<div class="description">
<div class="caption"><?= t("Description:") ?></div>
<div><?= p::clean($item->description) ?></div>
</div>
<? endif ?>
<? if ($item->id != 1): ?>
<div class="name">
<div class="caption"><?= t("Name:") ?></div>
<div><?= p::clean($item->name) ?></div>
</div>
<? endif ?>
<? if ($item->captured): ?>
<div class="captured">
<div class="caption"><?= t("Captured:") ?></div>
<div><?= date("M j, Y H:i:s", $item->captured)?></div>
</div>
<? endif ?>
<? if ($item->owner): ?>
<div class="owner">
<div class="caption"><?= t("Owner:") ?></div>
<div><a href="#"><?= p::clean($item->owner->name) ?></a></div>
</div>
<? endif ?>

Quote:

CSS
#gMetadata .gBlockContent div { padding-bottom: 4px; }
#gMetadata .gBlockContent div div { float: left; padding-right: 4px; }
#gMetadata .caption { font-weight: bold; }

bharat

Joined: 2002-05-21
Posts: 7994

Posted: Fri, 2009-06-19 00:37

Great! I've filed http://sourceforge.net/apps/trac/gallery/ticket/441 for our ui designers to look at this.
---
Problems: Check gallery3/var/logs first!
file a bug or feature request | upgrade to the latest code | use git

Serge D

Joined: 2009-06-11
Posts: 2466

Posted: Sun, 2009-06-21 20:21

Quote:

* Can Free Tiny-MCE editor be added by default for any editing needs? http://tinymce.moxiecode.com/

Ticket #449

Quote:

* Some clean up is required for current default CSS - "reset" CSS resets too much.

Ticket #450

Quote:

* Would be nice to define sidebars like it is done in WordPress

Ticket 451

thumb

Joined: 2004-05-26
Posts: 238

Posted: Mon, 2009-06-22 01:06

Thanks for the feedback Serge D. You can override use of tables in the info module's block by creating an override template in your theme.

I haven't had a chance to work on or think about sidebar block administration yet. A few quick thoughts:

* Modules will expose their blocks to specific view types, either album, photo, other module views, or some combination of these.

* Yes, drag and drop will be implemented in a similar fashion to the admin dashboard.

* A custom blocks module would also be nice, but is not a high priority for the initial release.

* It would nice to specify visibility rules to specify in which views a block may appear. Drupal supports this nicely with wildcard support.

I've just finished a quick draft sketch of the block admin UI and will post as soon. Themes will need to specify how many sidebars they have and they're location, either left or right. Sidebars might be specified in the .info file like this:

sidebar_right = 1 <-- One sidebar on the right

sidebar_left = 1 <-- One sidebar on the left and two on the right
sidebar_right = 2

Just a few thoughts, we'll see.

--
2tbsp.com

thumb

Joined: 2004-05-26
Posts: 238

Posted: Mon, 2009-06-22 01:09

I'll take a look at these tickets in the next few days.

--
2tbsp.com

Serge D

Joined: 2009-06-11
Posts: 2466

Posted: Mon, 2009-06-22 02:05

Quote:

Thanks for the feedback Serge D. You can override use of tables in the info module's block by creating an override template in your theme.

If I may ask, how can I create an override?

Quote:

I've just finished a quick draft sketch of the block admin UI and will post as soon. Themes will need to specify how many sidebars they have and they're location, either left or right. Sidebars might be specified in the .info file like this:

sidebar_right = 1 <-- One sidebar on the right

sidebar_left = 1 <-- One sidebar on the left and two on the right
sidebar_right = 2

Hopefully we can see it before final release

bharat

Joined: 2002-05-21
Posts: 7994

Posted: Mon, 2009-06-22 18:11

@Serge D: create a file in your theme/xxx/views directory called info_block.html.php and it will be used instead of the one that comes with the module.
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git | help! vote!

Serge D

Joined: 2009-06-11
Posts: 2466

Posted: Tue, 2009-06-23 14:00

If I may, I do not like how it structured
"Old" approach with "locale" was much easier to follow since it is nothing to do with the theme

thumb

Joined: 2004-05-26
Posts: 238

Posted: Tue, 2009-06-23 17:43

I'm not sure I understand. Are you saying you don't like like G2's approach with the use of the local folder? Or are you saying you don't like G3's approach?
--
2tbsp.com

Serge D

Joined: 2009-06-11
Posts: 2466

Posted: Tue, 2009-06-23 17:59

Quote:

create a file in your theme/xxx/views directory called info_block.html.php and it will be used instead of the one that comes with the module.

I do like G2 approach, I do not like G3 approach

bharat

Joined: 2002-05-21
Posts: 7994

Posted: Tue, 2009-06-23 23:54

G2 allowed both approaches: overriding in both the module and in the theme. That was overkill. Overriding in the module is a flawed approach because it makes upgrading modules difficult and spreads customizations all over the codebase. Centralizing all overrides in the theme keeps your modifications together. If this is causing you pain and you want it to be different, please present reasons.
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git | help! vote!

Serge D

Joined: 2009-06-11
Posts: 2466

Posted: Wed, 2009-06-24 03:16

Sorry, I was only using locale folder on module level for module modifications in G2.
My concern is that if I am to do "fixes" for the module it would expected to be a global change for the engine
Changes for the theme may be good but it should only be related to the theme.
In case above I want to change a global behaviour without being worry for the theme and be able to switch themes without copy customization all over.
I guess then I would be looking to support both as it were in G2

bharat

Joined: 2002-05-21
Posts: 7994

Posted: Sun, 2009-06-28 03:54

Sorry, the level of complexity there is not worth the trouble for us. I doubt that we'll support it.
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git | help! vote!

Serge D

Joined: 2009-06-11
Posts: 2466

Posted: Sun, 2009-06-28 16:30

ok

thumb

Joined: 2004-05-26
Posts: 238

Posted: Sun, 2009-06-28 22:55

I've just posted a draft spec for block administration user interface.

http://codex.gallery2.org/Gallery3:Block_Management_UX

Feedback is always appreciated.

--
2tbsp.com

thumb

Joined: 2004-05-26
Posts: 238

Posted: Sun, 2009-06-28 23:58

I just committed an update taking some, but not all, of your suggestions into account. Rather than divs, the block now uses an unordered list. I did not apply classes to each piece of metadata, you're free to do so in your block template override.

Thanks for the suggestion, using a list is much better visually than a table.

http://bit.ly/IQtmR

--
2tbsp.com

Serge D

Joined: 2009-06-11
Posts: 2466

Posted: Mon, 2009-06-29 06:15

I will check the new version with next roll

Serge D

Joined: 2009-06-11
Posts: 2466

Posted: Mon, 2009-06-29 06:24

thumb wrote:

I've just posted a draft spec for block administration user interface.
http://codex.gallery2.org/Gallery3:Block_Management_UX
Feedback is always appreciated.

Looks promissing and simple. Nice.

I am not sure why Drupal is in the picture

Serge D Joined: 2009-06-11 Posts: 2466	Posted: Fri, 2009-06-12 14:16
	Hi, First, a Great Job with a new version! Very easy conversion from 2.x. Few things I see as very important before final release: * Please do not use tables anywhere (<TABLE>). It is harder to manage via CSS. It does not buy you much other then easier block structures. Example is a metadata block. Try to put a big description there. * We need some sort of HTML tags support in descriptions * Can Free Tiny-MCE editor be added by default for any editing needs? http://tinymce.moxiecode.com/ * Some clean up is required for current default CSS - "reset" CSS resets too much. * Would be nice to define sidebars like it is done in WordPress
	XUser login Username: * Password: * Create new account Request new password
bharat Joined: 2002-05-21 Posts: 7994	Posted: Sun, 2009-06-14 01:58
	We use tables sparingly, but there are times when they make sense. Like on the admin/modules page. If you'd like to help us get rid of the existing tables we'd be happy to take the help. Create a fork on GitHub and start hacking on it and we'll pull your contributions into the main codebase when we've got it right. We will be adding HTML support to descriptions and other fields (http://sourceforge.net/apps/trac/gallery/ticket/400) We may eventually add something like TinyMCE, but it's not a focus for the 3.0 release. I'll point our UI guys at this thread to look into the reset issue I suspect we're going to do something similar to wordpress's sidebar approach, if we can figure out a simple way to do it. --- Problems? Check gallery3/var/logs before you post! and file bugs here! Latest code/upgrading: http://codex.gallery2.org/Gallery3:Upgrading Latest git: http://codex.gallery2.org/Gallery:Using_Git

Serge D Joined: 2009-06-11 Posts: 2466	Posted: Sun, 2009-06-14 05:09
	Thank you for follow up. I have no problem with tables in admin module, because the customization for it may be easier and information to display is limited. But when it comes to the gallery layout, flexibility is very important. I have migrated from G2 to G3 without problems, but limits now introduced within basic sidebar blocks makes appearance not very nice. I am still in process of creating a new theme (header, menu, basic colors), but you can see progress here http://photo.dragonsoft.us/index.php/california. You will notice that description in the sidebar makes it scroll. It is either that or cutoff text since table used just goes off the DIV. I will try to follow your suggestion though. I am looking forward to Beta 2 for HTML support. As far as sidebar blocks. You have the solution already - it works for dashboard - Easy and simple. Put it under "appearance" with page showing selector and sidebar modules (no content, just names) I would imagine that block settings could be exposed at some point, but it is not as important for this release. Ability to select blocks from available, and order them would be enough.

Serge D Joined: 2009-06-11 Posts: 2466	Posted: Thu, 2009-06-18 21:43
	bharat wrote: We use tables sparingly, but there are times when they make sense. Like on the admin/modules page. If you'd like to help us get rid of the existing tables we'd be happy to take the help. Create a fork on GitHub and start hacking on it and we'll pull your contributions into the main codebase when we've got it right. There goes the sample: http://photo.dragonsoft.us/index.php/california Changes: Quote: info_block.html.php <?php defined("SYSPATH") or die("No direct script access.") ?> <div class="title"> <div class="caption"><?= t("Title:") ?></div> <div><?= p::clean($item->title) ?></div> </div> <? if ($item->description): ?> <div class="description"> <div class="caption"><?= t("Description:") ?></div> <div><?= p::clean($item->description) ?></div> </div> <? endif ?> <? if ($item->id != 1): ?> <div class="name"> <div class="caption"><?= t("Name:") ?></div> <div><?= p::clean($item->name) ?></div> </div> <? endif ?> <? if ($item->captured): ?> <div class="captured"> <div class="caption"><?= t("Captured:") ?></div> <div><?= date("M j, Y H:i:s", $item->captured)?></div> </div> <? endif ?> <? if ($item->owner): ?> <div class="owner"> <div class="caption"><?= t("Owner:") ?></div> <div><a href="#"><?= p::clean($item->owner->name) ?></a></div> </div> <? endif ?> Quote: CSS #gMetadata .gBlockContent div { padding-bottom: 4px; } #gMetadata .gBlockContent div div { float: left; padding-right: 4px; } #gMetadata .caption { font-weight: bold; }

bharat Joined: 2002-05-21 Posts: 7994	Posted: Fri, 2009-06-19 00:37
	Great! I've filed http://sourceforge.net/apps/trac/gallery/ticket/441 for our ui designers to look at this. --- Problems: Check gallery3/var/logs first! file a bug or feature request \| upgrade to the latest code \| use git

Serge D Joined: 2009-06-11 Posts: 2466	Posted: Sun, 2009-06-21 20:21
	Quote: * Can Free Tiny-MCE editor be added by default for any editing needs? http://tinymce.moxiecode.com/ Ticket #449 Quote: * Some clean up is required for current default CSS - "reset" CSS resets too much. Ticket #450 Quote: * Would be nice to define sidebars like it is done in WordPress Ticket 451

thumb Joined: 2004-05-26 Posts: 238	Posted: Mon, 2009-06-22 01:06
	Thanks for the feedback Serge D. You can override use of tables in the info module's block by creating an override template in your theme. I haven't had a chance to work on or think about sidebar block administration yet. A few quick thoughts: * Modules will expose their blocks to specific view types, either album, photo, other module views, or some combination of these. * Yes, drag and drop will be implemented in a similar fashion to the admin dashboard. * A custom blocks module would also be nice, but is not a high priority for the initial release. * It would nice to specify visibility rules to specify in which views a block may appear. Drupal supports this nicely with wildcard support. I've just finished a quick draft sketch of the block admin UI and will post as soon. Themes will need to specify how many sidebars they have and they're location, either left or right. Sidebars might be specified in the .info file like this: sidebar_right = 1 <-- One sidebar on the right sidebar_left = 1 <-- One sidebar on the left and two on the right sidebar_right = 2 Just a few thoughts, we'll see. -- 2tbsp.com

thumb Joined: 2004-05-26 Posts: 238	Posted: Mon, 2009-06-22 01:09
	I'll take a look at these tickets in the next few days. -- 2tbsp.com

Serge D Joined: 2009-06-11 Posts: 2466	Posted: Mon, 2009-06-22 02:05
	Quote: Thanks for the feedback Serge D. You can override use of tables in the info module's block by creating an override template in your theme. If I may ask, how can I create an override? Quote: I've just finished a quick draft sketch of the block admin UI and will post as soon. Themes will need to specify how many sidebars they have and they're location, either left or right. Sidebars might be specified in the .info file like this: sidebar_right = 1 <-- One sidebar on the right sidebar_left = 1 <-- One sidebar on the left and two on the right sidebar_right = 2 Hopefully we can see it before final release

bharat Joined: 2002-05-21 Posts: 7994	Posted: Mon, 2009-06-22 18:11
	@Serge D: create a file in your theme/xxx/views directory called info_block.html.php and it will be used instead of the one that comes with the module. --- Problems? Check gallery3/var/logs bugs/feature req's \| upgrade to the latest code \| use git \| help! vote!

Serge D Joined: 2009-06-11 Posts: 2466	Posted: Tue, 2009-06-23 14:00
	If I may, I do not like how it structured "Old" approach with "locale" was much easier to follow since it is nothing to do with the theme

thumb Joined: 2004-05-26 Posts: 238	Posted: Tue, 2009-06-23 17:43
	I'm not sure I understand. Are you saying you don't like like G2's approach with the use of the local folder? Or are you saying you don't like G3's approach? -- 2tbsp.com

Serge D Joined: 2009-06-11 Posts: 2466	Posted: Tue, 2009-06-23 17:59
	Quote: create a file in your theme/xxx/views directory called info_block.html.php and it will be used instead of the one that comes with the module. I do like G2 approach, I do not like G3 approach

bharat Joined: 2002-05-21 Posts: 7994	Posted: Tue, 2009-06-23 23:54
	G2 allowed both approaches: overriding in both the module and in the theme. That was overkill. Overriding in the module is a flawed approach because it makes upgrading modules difficult and spreads customizations all over the codebase. Centralizing all overrides in the theme keeps your modifications together. If this is causing you pain and you want it to be different, please present reasons. --- Problems? Check gallery3/var/logs bugs/feature req's \| upgrade to the latest code \| use git \| help! vote!

Serge D Joined: 2009-06-11 Posts: 2466	Posted: Wed, 2009-06-24 03:16
	Sorry, I was only using locale folder on module level for module modifications in G2. My concern is that if I am to do "fixes" for the module it would expected to be a global change for the engine Changes for the theme may be good but it should only be related to the theme. In case above I want to change a global behaviour without being worry for the theme and be able to switch themes without copy customization all over. I guess then I would be looking to support both as it were in G2

bharat Joined: 2002-05-21 Posts: 7994	Posted: Sun, 2009-06-28 03:54
	Sorry, the level of complexity there is not worth the trouble for us. I doubt that we'll support it. --- Problems? Check gallery3/var/logs bugs/feature req's \| upgrade to the latest code \| use git \| help! vote!

Serge D Joined: 2009-06-11 Posts: 2466	Posted: Sun, 2009-06-28 16:30
	ok

thumb Joined: 2004-05-26 Posts: 238	Posted: Sun, 2009-06-28 22:55
	I've just posted a draft spec for block administration user interface. http://codex.gallery2.org/Gallery3:Block_Management_UX Feedback is always appreciated. -- 2tbsp.com

thumb Joined: 2004-05-26 Posts: 238	Posted: Sun, 2009-06-28 23:58
	I just committed an update taking some, but not all, of your suggestions into account. Rather than divs, the block now uses an unordered list. I did not apply classes to each piece of metadata, you're free to do so in your block template override. Thanks for the suggestion, using a list is much better visually than a table. http://bit.ly/IQtmR -- 2tbsp.com

Serge D Joined: 2009-06-11 Posts: 2466	Posted: Mon, 2009-06-29 06:15
	I will check the new version with next roll

Serge D Joined: 2009-06-11 Posts: 2466	Posted: Mon, 2009-06-29 06:24
	thumb wrote: I've just posted a draft spec for block administration user interface. http://codex.gallery2.org/Gallery3:Block_Management_UX Feedback is always appreciated. Looks promissing and simple. Nice. I am not sure why Drupal is in the picture

Page layouts and tables

XUser login